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

[Vadim Goncharov <vadimnuclight%gmail.com@localhost>]

On Fri, 6 Jun 2025 14:21:05 +0000
Emmanuel Nyarko <emmankoko519%gmail.com@localhost> wrote:

> > On 6 Jun 2025, at 2:07 PM, Vadim Goncharov <vadimnuclight%gmail.com@localhost> wrote:
> > 
> > On Fri, 6 Jun 2025 08:45:43 -0400
> > Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> >   
> >> On Fri, Jun 06, 2025 at 07:33:37AM +0000, Emmanuel Nyarko wrote:  
> >>>   
> >>>> On 5 Jun 2025, at 11:12???PM, Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> >>>> 
> >>>> What will happen when a socket changes hands by file descriptor passing
> >>>> over a Unix domain socket?    
> >>> 
> >>> But the reason is I want to add this support is for NPF to be able to
> >>> give a user based security to Unix servers in network layer. Like being
> >>> able to allow or deny certain users on a server from giving out
> >>> resources. so maybe for now, even if I???m doing it as opt-in, I can
> >>> still exempt UDS from it because I don???t think it will add anything to
> >>> Unix Domain Sockets    
> >> 
> >> I don't think you understand.  I can accept a TCP connection on an AF_INET
> >> socket, then take the resulting file descriptor and transfer it to a
> >> completely unrelated process using a control message on an AF_UNIX socket.
> >> That process can be owned by a different user.  What do you intend to
> >> happen to the AF_INET socket that is passed in this way?  
> > 
> > Does that matter at all? For the common needed case, e.g. FreeBSD's ipfw(8)
> > has uid/gid (and then also jail id) support for decades - not without
> > layering violation problems in code, though. The BUGS section lists:
> > 
> >     Rules using uid or gid may not behave as expected.  In particular,
> >     incoming SYN packets may have no uid or gid associated with them since
> >     they do not yet belong to a TCP connection  
> listening sockets are loaded into the pcb table in NetBSD AFAIK. So can
> easily locate the socket using a daddr and dport lookup for them sockets.
> And that should be easily found. Maybe FreeBSD doesn’t load the
> bound/listening sockets into the pcbtable.

FreeBSD also uses inpcb table as derived from common BSD ancestor. Actually
"layering violation problems" means "locking problems" - how to do things both
correct and fast on SMP systems, caching (stale info) and so on.

> > , and the uid/gid associated
> >     with a packet may not be as expected if the associated process calls
> >     setuid(2) or similar system calls.  
> 
> > 
> > -- 
> > WBR, @nuclight  
> 
> A scoffer seeks wisdom in vain, but knowledge is easy for a man of
> understanding. Emmanuel

-- 
WBR, @nuclight