Thor Lancelot Simon <t...@panix.com> 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.
