diff options
Diffstat (limited to 'open_issues/sendmsg_scm_creds.mdwn')
| -rw-r--r-- | open_issues/sendmsg_scm_creds.mdwn | 77 |
1 files changed, 74 insertions, 3 deletions
diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn index cf0103df..d4a6126e 100644 --- a/open_issues/sendmsg_scm_creds.mdwn +++ b/open_issues/sendmsg_scm_creds.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -11,7 +11,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc]] -IRC, unknown channel, unknown date. + +# 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 @@ -91,10 +92,80 @@ IRC, unknown channel, unknown date. <pinotree> yep <youpi> ok, good :) -/!\ IRC, freenode, #hurd, 2011-08-11 + +## 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 |