[systemd-devel] Antw: [EXT] Re: Accpetance of Environment Variables in Attributes
Lennart Poettering
lennart at poettering.net
Fri Jun 26 13:42:10 UTC 2020
On Fr, 26.06.20 14:03, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> Ulrich Windl wrote on 26/06/2020 10:43:
> >>>> Roman Odaisky <roma at qwertty.com> schrieb am 25.06.2020 um 14:35 in
> > Nachricht
> > <2175_1593088566_5EF49A35_2175_217_1_5367023.DvuYhMxLoT at xps>:
> >>> [Service]
> >>> User=nobody
> >>
> >> May I interject that DynamicUser=yes is generally superior to User=nobody.
> >
> > And I always thought the user is named nobody, because no process ever using
> > it (as UID to run with)...
> > Using it may have unwanted security implications.
>
> Could be wrong, but I think it's more to do with running *multiple*
> unrelated services as nobody. They could, in theory, mess with each
> other in some cases (deleting each others temporary files, sockets etc).
> So one dodgy/vulnerable "nobody" service could then interfere with a
> more robust "nobody" service just because they are running as the same user.
>
> Running as different users can avoid that vector.
The primary purpose of "nobody" these days is to be the "overflow"
user, i.e. the stuff that otherwise is not mappable gets owned by. For
example, NFS clients that encounter unmappable users map them to
"nobody" because it needs to map it somewhere. Similar, if user
namespacing is used and there's a UID that is not mappable with the
current namespace's UID mapping, then it gets mapped to "nobody".
If you run binaries under that UID they'll hence get access to stuff
they really should not get access to, nobody should in fact, hence
these files are actually owned by just that, a user "nobody".
If you use the "nobody" user in User= you are doing things wrong.
And we probably should start warning about that...
Lennart
--
Lennart Poettering, Berlin
More information about the systemd-devel
mailing list