[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Svante Signell
Subject: RFC: [PATCH] SCM_CREDS support
Date: Thu, 24 Oct 2013 13:40:02 +0200


New patch, now receiver centric, as requested for SCM_CREDS support for
GNU/Hurd: scm_creds_sendmsg.c.diff and scm_cresd_recvmsg.c.

(previous second patch, (updated scm_creds-sendmsg.c_2.diff) for the
-n option, might not be used, in that case the first attached
(scm_creds-sendmsg.c.diff) patch will change accordingly.

We are now checking authorization on the receive side. There are still
some FIXMEs that need to be resolved.  Maybe som more cleanup and
locking, etc is needed. Additionally, maybe sending two ports to
the receiver with the corresponding check on the receiver side is not
enough security, therefore this RFC. 

I've been running two kvm-images with eglibc built with this patch for
a few days now, and haven't seen any problems so far. On the list of
things running properly with SCM_CREDS support are:

- All 11 gamin tests OK
- All 15+2 dbus tests OK (with upstream patches)
- 171+ of 182 glib2.0 tests OK (with upstream patches)
- Many more window managers, web browsers and X applications work
- emacs works in X (when built with patched eglibc)
- gdm3 builds (to be tested) - ...

This patch implements the first cases in the test code sent to the list
in September 2013, options <no flag> (and -z), see

Option -z (used by dbus) is no longer a special case, same behaviour as

no flag: 
-z: send a zero credentials byte as data (used by dbus)
(no difference with w/o in the current implementation)

1) Sent credentials and PID are correct:
a) ./scm_cred_recv &
Linux: OK, only sent IDs
kFreeBSD: OK, sent IDs + groups (irrespective of sent IDs)
Hurd: OK,same as kfreebsd
see /usr/include/i386-gnu/bits/socket.h:
/* Structure delivered by SCM_CREDS.  This describes the identity of the
   sender of the data simultaneously received on the socket.  By BSD
   convention, this is included only when a sender on a AF_LOCAL socket
   sends cmsg data of this type and size; the sender's structure is
   ignored, and the system fills in the various IDs of the sender process.  */
struct cmsgcred

b)./scm_cred_recv -z&
./scm_cred_send -z
Linux: OK, same as above
kFreeBSD: OK, same as above
Hurd: OK, same as above

2) When wrong credentials are sent the behaviour is different:
no flag: ERROR [EPERM Operation not permitted] sendmsg
-z: ERROR [EPERM Operation not permitted] sendmsg

no flag: sent credentials are not honoured, received ones are created
-z: sent credentials are not honoured, received ones are created

same as kfreebsd

Attachment: scm_creds-sendmsg.c.diff
Description: Text Data

Attachment: scm_creds-recvmsg.c.diff
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]