Re: Proposal to automatically make the owner/user of an accepted socket the current process

Thor Lancelot Simon <[email protected]> writes:

>> It may be that the firewall rules should be based on the process's
>> uid/gid, and that the concept of sockets having owners is just a red herring.
>
> Indeed.  Maybe it's helpful to think about SO_PEERCRED.  On NetBSD, this
> operation is defined only for AF_UNIX sockets, but for a Linux system,
> SO_PEERCRED works on TCP sockets *if the peer is on the same host*.  It
> returns the peer's euid.  Is that's what's wanted here, but for the local,
> not the remote, end of the connection?  It sounds to me like it might be.
>
> However, there are funny corner cases, like if we intentionally drop
> privileges.  A single UID may not be enough, and as I think about it,
> I don't think even the mess of POSIX saved UID semantics are sufficient.

I suspect that most of what is wanted is "let daemon program A run as
user A' only do X".   At least that's what I want.

In npf, that leads to wanting to ask

  get me the effective uid/gid of the process that sent this packet

and, much much less well understood by me

  get me the effective uid/gid of the process which will receive this
  packet after I deliver it to socket B


which raises the question of firewall rules for originated/delivered
packets separately from received/output packets, that I brought up earlier.