Re: Extending sockcred

["Matthew Mondor" <mm_lists%pulsar-zone.net@localhost>]

On Saturday, 5 Jul 2008 5:53:05
"Matthew Mondor" <mm_lists%pulsar-zone.net@localhost> 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
functionality.

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