[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" <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
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.
Main Index |
Thread Index |