Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.

1 files changed, 172 insertions, 0 deletions

diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn
new file mode 100644
index 00000000..d4a6126e
--- /dev/null
+++ b/open_issues/sendmsg_scm_creds.mdwn
@@ -0,0 +1,172 @@
+[[!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]].