Re: Proposal to automatically make the owner/user of an accepted socket the current process
Vadim Goncharov <[email protected]> Fri, 6 Jun 2025 17:54:13 +0300
| Newsgroups | gmane.os.netbsd.devel.network,gmane.os.netbsd.devel.kernel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 6 Jun 2025 14:21:05 +0000 Emmanuel Nyarko <[email protected]> wrote: > > 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. 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