rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 172 deletions

diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn
deleted file mode 100644
index d4a6126e..00000000
--- a/open_issues/sendmsg_scm_creds.mdwn
+++ /dev/null
@@ -1,172 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_glibc]]
-
-
-# IRC, unknown channel, unknown date
-
-    <pinotree> Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2722
-    <pinotree> 2722: Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2724
-    <pinotree> \o/
-    <youpi> \o/
-    <pinotree> the patch is even short, after all: http://paste.debian.net/54795/
-    --- a/sysdeps/mach/hurd/sendmsg.c
-    +++ b/sysdeps/mach/hurd/sendmsg.c
-    @@ -18,6 +18,7 @@
-     
-     #include <errno.h>
-     #include <string.h>
-    +#include <unistd.h>
-     #include <sys/socket.h>
-     #include <sys/un.h>
-     
-    @@ -45,6 +46,7 @@
-       mach_msg_type_number_t amount;
-       int dealloc = 0;
-       int i;
-    +  struct sockaddr_storage sa;
-     
-       /* Find the total number of bytes to be written.  */
-       len = 0;
-    @@ -122,6 +124,34 @@
-       err = EIEIO;
-         }
-     
-    +  memset (&sa, 0, sizeof (struct sockaddr_storage));
-    +  if (addr)
-    +    {
-    +      memcpy (&sa, addr, addr_len);
-    +    }
-    +  else
-    +    {
-    +      getsockname (fd, (struct sockaddr *) &sa, &addr_len);
-    +    }
-    +  addr = (struct sockaddr_un *) &sa;
-    +  if (message && (addr->sun_family == AF_LOCAL))
-    +    {
-    +      struct cmsghdr *cm;
-    +      struct msghdr *m = (struct msghdr *) message;
-    +      for (cm = CMSG_FIRSTHDR (m); cm; cm = CMSG_NXTHDR (m, cm))
-    +      {
-    +        if (cm->cmsg_level == SOL_SOCKET && cm->cmsg_type == SCM_CREDS)
-    +	     {
-    +	           struct cmsgcred *cred = (struct cmsgcred *) CMSG_DATA (cm);
-    +		         cred->cmcred_pid = __getpid ();
-    +			       cred->cmcred_uid = __getuid ();
-    +			             cred->cmcred_euid = __geteuid ();
-    +				           cred->cmcred_gid = __getgid ();
-    +					         cred->cmcred_ngroups = getgroups (sizeof (cred->cmcred_groups) / sizeof (gid_t), cred->cmcred_groups);
-    +						     }
-    +						     }
-    +    }
-    +
-       err = HURD_DPORT_USE (fd,
-           	 ({
-    			  if (err)
-    <youpi> what checks that the pid is correct?
-    <youpi> and uid, etc.
-    <pinotree> hm?
-    <youpi> credential is not only about one claiming to the other his uid & such
-    <youpi> it's about the kernel or whatever authority tell to an end the identity of the other end
-    <pinotree> yep
-    <pinotree> but given that the data is then send to pflocal, this code is the last part that runs on the application side
-    <youpi> pflocal could as well just request the info from proc
-    <youpi> it will have to anyway, to check that it's true
-    <pinotree> hm
-    <pinotree> yeah, though about that, chose this approach as "quicker" (of course not definitive)
-    <youpi> well at least it shows we're able to transmit something :)
-    <pinotree> well it just manipulates the data which gets send nicely already ;)
-    <youpi> but really, it's most probably up to pflocal to check authentication from proc and give it to the other end
-    <youpi> the application sender part would be just the RPC authentication calls
-    <youpi> Mmm, just realizing: so receiver part already exists actually, right?
-    <youpi> (since it's just about letting the application reading from the message structure)
-    <pinotree> yep
-    <youpi> ok, good :)
-
-
-## IRC, freenode, #hurd, 2011-08-11
-
-    < pinotree> (but that patch is lame)
-
-
-## IRC, freenode, #hurd, 2013-05-09
-
-    <gnu_srs> youpi: Since you are online tonight, which authentication
-      callbacks to be used for SCM_CREDS calls. 
-    <gnu_srs> I have working code and need to add this to make things
-      complete. The auth server, lib* or where?  
-    <youpi> I don't understand the question
-    <gnu_srs> authentication callbacks like for SCM_RIGHTS, see 
-    <gnu_srs>
-      http://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html
-    <youpi> I still don't understand: what are you trying to do actually?
-    <gnu_srs> solving the SCM_CREDS propbems with e.g. dbus.
-    <youpi> so what is the relation with pinotree's patch on the page above?
-    <youpi> (I have no idea of the current status of all that)
-    <gnu_srs> his patch was not merged, right? have to shut down, sorry, bbl,
-      gn8
-    <pinotree> that patch was not merged since it is not in the correct place
-    <youpi> as I said, I have no idea about the status
-    <pinotree> youpi: basically, it boils down to knowing, when executing the
-      code implementing an rpc, who requested that rpc (pid, uid, gid)
-    <youpi> i.e. getting information about the reply port for instance?
-    <youpi> well that might be somehow faked
-    <youpi> (by perhaps giving another task's port as reply port)
-    <pinotree> for example (which would be the code path for SCM_CREDS), when
-      you call call the socket sendmsg(), pflocal would know who did that rpc
-      and fill the auxilliary data)
-    <pinotree> s,)$,,
-    <pinotree> youpi: yes, i know about this faking issue, iirc also antrik
-      mentioned quite some time ago
-    <youpi> ok
-    <pinotree> that's one of the (imho) two issues of this
-    <pinotree> my hurd-foo is not enough to know whether there are solutions to
-      the problem above
-
-
-### IRC, freenode, #hurd, 2013-05-14
-
-    <gnu_srs> Hi, regarding SCM_CREDS, I have some working code in
-      sendmsg.c. Now I need to make a callback to authenticate the pid, uid,
-      etc
-    <gnu_srs> Where to hook call that into pflocal? 
-    <gnu_srs> the auth server?
-    <gnu_srs> maybe _io_restrict_auth is the correct call to use (same as for
-      SCM_RIGHTS)?
-
-
-### IRC, freenode, #hurd, 2013-05-17
-
-    <gnu_srs> I'm working on the scm credentials right now to enable (via dbus)
-      more X window managers to work properly.
-    <gnu_srs> seems to be rather tricky:-(
-    <pochu> gnu_srs: I guess you also need SCM_CREDS, right?
-    <gnu_srs> hi pochu, that's what I'm working on, extending your SCM_RIGHTS
-      work to SCM_CREDS
-    <pinotree> that's what i did as proof, years ago?
-    <gnu_srs> it would be good to know which server calls to make, I'll be back
-      with proposals of functions to use.
-    <pinotree> there was a talk, years ago when i started with this, and few
-      days ago too
-    <pinotree> every methods has its own drawbacks, and basically so far it
-      seems that in every method the sender identity can be faked somehow
-    <gnu_srs> pinotree: Yes of course your patch was perfect, but it seemed
-      like people wanted a server acknowledgement too.
-    <pinotree> no, my patch was not perfect at all
-    <pinotree> if it was, it would have been cleaned up and sent few years ago
-      already
-
-
----
-
-See also [[dbus]], [[pflocal_socket_credentials_for_local_sockets]] and
-[[pflocal_reauth]].