Hey Mantas,
Thanks for the reply.
On Wed, Mar 4, 2020 at 12:06 PM Mantas Mikulėnas <graw...@gmail.com> wrote:
> On Wed, Mar 4, 2020 at 7:26 PM Matt Zagrabelny <mzagr...@d.umn.edu> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
