x/net/unix: support credentials on unix sockets

[rminnich]

It would be useful to have these three functions:
func (c *UnixConn) Pid (pid int, err os.Error)

func (c *UnixConn) Uid (uid int, err os.Error)

func (c *UnixConn) Gid (gid int, err os.Error)

or even this:
func (c *UnixConn) PeerCred (pid, uid, gid int, err os.Error)

These are returned by SO_PEERCRED. This info is used just often enough
that these functions would come in
very handy.

I would submit a patch but my lawyers are still working on the CLA.

Thanks

ron

[rminnich]

Comment 1:

Sorry about that useless issue subject, hit the button too soon :-(

[rsc]

Comment 2:

Status changed to Accepted.

[alberts]

Comment 3:

We are also interested in a related issue, namely sending file descriptors using       
SCM_RIGHTS.

[alberts]

Comment 4:

The best interface I could come up with is:
func (c *UnixConn) SendRights(fds []os.File) os.Error
func (c *UnixConn) SendCredentials(cred Ucred) os.Error
func (c *UnixConn) ReceiveAncillary() (fds []os.File, cred []Ucred, err os.Error)
As far as I understand the documentation, recvmsg can receive a mixed bag of cmsgs, so
there's no way of separating them beforehand.
Comments?

[bradfitz]

Comment 5:

rather than sending/receiving os.File, which is:
type File struct {
    fd      int
    name    string
    dirinfo *dirInfo // nil unless directory being read
    nepipe  int      // number of consecutive EPIPE in Write
}
... why not just send the fd int?  We wouldn't have a name, dirinfo, or nepipe, anyway?
If they want an os.File they can make one with os.Newle(fd int, name string) *os.File

[alberts]

Comment 6:

As discussed here:
http://groups.google.com/group/golang-nuts/browse_thread/thread/73a5186029a8d670
it seems most of sockets, pipes, etc. will be getting a Fd() that returns *os.File, so
based on that I reasoned that defining the API in terms of os.File made more sense.
As you pointed out, ReceiveAncillary will have to use os.NewFile then...

[alberts]

Comment 7:

More discussion:
http://groups.google.com/group/golang-dev/t/464c20c2e8363a92
Having a ReceiveAncillary on its own isn't going to work.

[alberts]

Comment 8:

Something to look out for: The kernel doesn't translate PIDs in SCM_CREDENTIALS across
PID namespaces (bug in 2.6.30).
Google Breakpad has some code related to this:
http://google-breakpad.googlecode.com/svn-history/r515/trunk/src/client/linux/crash_generation/crash_generation_server.cc

[alberts]

Comment 9:

Work in progress is here:
http://golang.org/cl/2331044/
Hopefully this will get merged soon, after which we can tackle the high-level API.

[davecheney]

Comment 10:

Hi Fullung, 
2331044 was merged some time ago, what are the next steps from here ?

[alberts]

Comment 11:

We have the functionality to send and receive bytes using sendmsg/recvmsg, but we need
to create some functions to go from the specific ancillary messages to []byte and back.
For SCM_CREDENTIALS, we need to convert syscall.Ucred to bytes. We also need an API to
enable SO_PASSCRED on the socket.
SCM_RIGHTS is more tricky. In C there's a bunch of CMSG_* macros for packing in the file
descriptors you want to send. See man 3 cmsg. Up until now I've just wrapped these
macros with cgo, but that's probably not ideal.
I've written some test code to this stuff. I'll upload it on Monday.

[alberts]

Comment 12:

Here's some test code I used at one point:
http://codereview.appspot.com/download/issue2331044_53001_54003.diff
Also, there was another CL to fix Recvmsg:
http://golang.org/cl/3766042
I've also attached some code for dealing with cmsg. But we probably want to do something
that doesn't depend on cgo.

Attachments:

1. cmsg.h (367 bytes)
2. net_test.go (1424 bytes)
3. cmsg.go (1654 bytes)

[alberts]

Comment 13:

http://www.normalesup.org/~george/comp/libancillary/
might provide some inspiration.

[rsc]

Comment 14:

Labels changed: added priority-later.

[alberts]

Comment 15:

syscall/sockcmsg_linux.go and syscall/sockcmsg_unix.go has more stuff in this area these
days. Maybe it's good enough?