Re: [PATCH v2] socket.7: Document some BPF-related socket options

["Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Hello Vincent,

On 03/01/2016 05:36 PM, Vincent Bernat wrote:
>  ❦  1 mars 2016 11:31 -0500, Craig Gallek <kraigatgoog@gmail.com> :
> 
>>> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html