tech-kern archive

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

Re: Extending sockcred

On Saturday, 5 Jul 2008 5:53:05
"Matthew Mondor" <> wrote:

> Unfortunately, I only noticed LOCAL_PEEREID after I
> implementedLOCAL_PROC as I finally added the new #define to un.h
> :) and LOCAL_PROC semantics are like LOCAL_CREDS ones.  I'll
> consider postinga diff in a PR if I have to fix LOCAL_PEEREID to
> work with SOCK_DGRAM.

So after testing, LOCAL_PEEREID getsockopt(2), other than requireing
an extra syscall per packet if it worked, indeed returns EINVAL in
this case since a SOCK_DGRAM socket.  Moreover, it unfortunately does
not provide the process group which my application also requires.

I'll try to see if this LOCAL_PEEREID has precedent before modifying
its return structure or semantics, however.

Considering that LOCAL_PEEREID is mostly redundant with LOCAL_CREDS
and more restrictive (although it does provide the pid_t), and that
the tree already has both, would yet another more powerful LOCAL_CREDS
variant be allowed in the official tree?  I have a working LOCAL_PROC
implementation which combines LOCAL_CREDS and LOCAL_PEEREID

Perhaps there also could be a better generic way to add this
functionality without always being stuck with ABI trouble when
extension occurs, or having to add yet another redundant custom type. 
A versionned structure with only wanted elements filled according to
specified flags?  A property-based system (this would however still
need to be efficient)?  Suggestions are welcome.
Matthew Mondor

Home | Main Index | Thread Index | Old Index