Re: AF_INET socket ownership

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Mantas,

Thanks for the reply.

On Wed, Mar 4, 2020 at 12:06 PM Mantas Mikulėnas <grawity@xxxxxxxxx> wrote:
On Wed, Mar 4, 2020 at 7:26 PM Matt Zagrabelny <mzagrabe@xxxxxxxxx> wrote:
Greetings,

Do folks use non-root users to own AF_INET sockets

This bit *really* doesn't make sense.

Sure. That is why I asked if it was even a sensible question.
 
You're not changing the socket ownership in your examples at all -- you're changing the *service's* user account.

Agreed. I wasn't trying to imply that I was changing socket ownership. Agreed - I did mean to change the user that the service runs as.

 
Who owns the socket has nothing to do with who owns the service process. (And the socket is still owned by root, as the whole point of .socket units is that socket creation is handled by pid1.)

Okay. I wasn't sure if pid1 (systemd) could create the AF_INET socket and have it owned by another user. Sort of like the AF_UNIX socket ownership:

       SocketUser=, SocketGroup=
           Takes a UNIX user/group name. When specified, all AF_UNIX sockets and FIFO nodes in the file system are owned by the specified user and
           group. If unset (the default), the nodes are owned by the root user/group (if run in system context) or the invoking user/group (if run in
           user context). If only a user is specified but no group, then the group is derived from the user's default group.
 

Indeed a very common use case for socket activation (including the original inetd) is to have a privileged process create the socket, then pass it to an unprivileged process. But it's the opposite of what you describe -- the socket is owned by root but the daemon process isn't.


Sure.
 

Either way, that's not specific to systemd .socket units at all -- many services *already* work like that. You'll find many instances of services having their own user accounts (httpd has its own, mariadb has its own, sshd has its own...) Some of them even implement the "privileged listener" model internally, e.g. httpd and sshd.

Okay.

Thanks for the dialog and help!

-m
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux