Hello Vincent,
On 03/01/2016 05:36 PM, Vincent Bernat wrote:
> ❦ 1 mars 2016 11:31 -0500, Craig Gallek <kraigatgoog@xxxxxxxxx> :
>
>>> But, what about the second paragraph mentioned in my other mail. I
>>> think we should just kill it. What do you think?
>> Ah, that's an interesting question... I believe the 'typical use
>> case' paragraph is correct with removal of the 'privilege' qualifiers
>> (and pretty much lifted from the commit message), but I'll defer to
>> you as to whether or not it's appropriate for a man page. There don't
>> appear to be other such examples in this specific page and anyone who
>> is really interested in the motivation behind the implementation of a
>> feature is better off looking at the code and commit messages
>> anyway...
>
> The typical use case is still about privileges since a fully privileged
> process could just create a similar socket without the filter. It makes
> little sense to create a socket, add a filter and lock it if you keep
> your privileges.
Thanks. That, plus a reread of the commit message was the info I needed.
The point here is that we're talking about raw sockets, right? I
reworded that paragraph to:
The typical use case is for a privileged process to set
up a raw socket (an operation that requires the
CAP_NET_RAW capability), apply a restrictive filter, set
the SO_LOCK_FILTER option, and then either drop its
privileges or pass the socket file descriptor to an
unprivileged process via a UNIX domain socket.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
