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