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

> On 6 Jun 2025, at 12:45 PM, Greg Troxel <[email protected]> wrote:
> 
> I think we need to step back and first establish requirements and goals.
> 
> It makes sense to me to be able to use uid/gid as a selector in firewall
> rules.  I don't agree that making rules about socket creation/binding is
> sufficient.  I can think of a specific use for a program with its
> associated uid that I would want to write per-program (per-uid) rules
> for.
> 
> While not addressing colluding programs, one could run program A as user
> A, and then write rules that user A can only send/receive to some
> particular prefix, or to specific addresses and ports.  This happens on
> Android, e.g. in CalyxOS, where one can turn on/off network access per
> app (which is per uid because that's how apps work on Android),
> selecting wifi/cell/vpn separately.
> 
> The question of what happens to a listen-cloned socket that is handed to
> a non-privileged process from a root-created listen socket is a good
> one.  I see the point of previous comments that the proper uid is not
> obvious and not one-size-fits-all.  But I can very much see the point of
> wanting the unprivileged user to own the socket, or really to be the uid
> that is used in firewall lookups.
> 
> Turning this around, why is a listen socket owned by root anyway, for a
> non-root daemon?  It might be just because of privileged port, and no
> other reason, so perhaps that deserves a changed uid anyway.
> 
> 
> Unix-domain sockets are perahps another matter, and perhaps not.  We
> don't have the ability to firewall them.  Perhaps we should, but it
> doesn't seem pressing.
Maybe that’s for another day.
> 

A scoffer seeks wisdom in vain, but knowledge is easy for a man of understanding.
Emmanuel