diff options
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/sendmsg_scm_creds.mdwn')
| -rw-r--r-- | service_solahart_jakarta_selatan__082122541663/sendmsg_scm_creds.mdwn | 172 |
1 files changed, 172 insertions, 0 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/sendmsg_scm_creds.mdwn b/service_solahart_jakarta_selatan__082122541663/sendmsg_scm_creds.mdwn new file mode 100644 index 00000000..d4a6126e --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/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]]. |