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

> On 6 Jun 2025, at 2:07 PM, Vadim Goncharov <[email protected]> wrote:
> 
> On Fri, 6 Jun 2025 08:45:43 -0400
> Thor Lancelot Simon <[email protected]> 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 <[email protected]> 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.
> , 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