Re: Antw: [EXT] Re: Accpetance of Environment Variables in Attributes

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

 



On Fr, 26.06.20 14:03, Colin Guthrie (gmane@xxxxxxxxxxxxxx) wrote:

> Ulrich Windl wrote on 26/06/2020 10:43:
> >>>> Roman Odaisky <roma@xxxxxxxxxxx> schrieb am 25.06.2020 um 14:35 in
> > Nachricht
> > <2175_1593088566_5EF49A35_2175_217_1_5367023.DvuYhMxLoT@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
_______________________________________________
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