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.