IRC.

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