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

> On 6 Jun 2025, at 9:18 AM, Robert Elz <[email protected]> wrote:
> 
>    Date:        Fri, 6 Jun 2025 07:33:37 +0000
>    From:        Emmanuel Nyarko <[email protected]>
>    Message-ID:  <[email protected]>
> 
>  | 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.
> 
> Personally, I think your design is flawed from the outset, and looks to
> be more a way to justify the addition you made to npf rather than anything
> that can realistically work (for any practical benefit).

Personally, I just though it would be cool if we are able to use the feature to run
 a user-based server protection across the entire machine. That’s why I came to you the experienced guys.

But if you say it’s flawed, then I guess, I will still be researching into it. Would also be happy if there’s possibly a better design.
> 
> If you want to control user's network access, the time to control it
> would be when the local user is connecting a socket, or binding to one
> for receiving (or in sendto()/recvfrom() for UDP packets) - rather than
> packet by packet as they're being sent/received over the network.
I get this. Tried with a few and realized it does it easily with connecting users. No root-restrictions.
> 
> Just possibly rate limiting might be possible using the local user ID,
> and packet streams, but that wouldn't be easy either.
I could research into this as well. 
> 
> For remote users, the time to say yes/no would be when they're authenticating
> themselves to your local system - when using some protocol which doesn't
> do that, then you simply cannot do per user control, as there is no way
> to know who is out there.

> All the discussion about user domain sockets, is, perhaps, because readers
> of this thread simply assumed that's what you were talking about, as that
> is a place where uids and ownership of the sockets makes some sense.
> 
> But as you say, that's not what you mean.  I just don't believe that the
> way you're trying to do things can possibly work.
Thanks for the clarity.
> 
> kre
> 

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