<div dir="ltr"><div dir="ltr">On Wed, Mar 4, 2020 at 7:26 PM Matt Zagrabelny <<a href="mailto:mzagrabe@d.umn.edu">mzagrabe@d.umn.edu</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Greetings,<div><br></div><div>Do folks use non-root users to own AF_INET sockets</div></div></blockquote><div><br></div><div>This bit *really* doesn't make sense. You're not changing the socket ownership in your examples at all -- you're changing the *service's* user account. 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.)</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>