7:39 a.m.
Heya!
I'd like to start a discussion regarding the "nobody" user on Fedora,
and propose that we change its definition sooner or later. I am not
proposing a feature according to the feature process for this yet, but
my hope is that these discussions will lead to one eventually.
Most distributions (in particular Debian/Ubuntu-based ones) map the
user "nobody" to UID 65534. I think we should change Fedora to do the
same. Background:
On Linux two UIDs are special: that's UID 0 for root, which is the
privileged user we all know. And then there's UID 65534
(i.e. (uint16_t) -2), which is less well known. The Linux kernel calls
it the "overflow" UID. It has four purposes:
1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs
only supports 16bit UIDs, but a 32bit UID is passed to it.
2. it's used by the kernel's user namespacing as a the internal UID
that external UIDs are mapped to that don't have any local mapping.
3. It's used by NFS for all user IDs that cannot be mapped locally if
UID mapping is enabled.
4. One upon a time some system daemons chose to run as the "nobody"
user, instead of a proper system user of their own. But this is
universally frowned upon, and isn't done on any current systems
afaics. In fact, to my knowledge Fedora even prohibits this
explicitly in its policy (?).
The uses 1-3 are relevant today, use 4 is clearly obsolete
afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something
that cannot be mapped properly is mapped to".
On Fedora, we currently have a "nobody" user that is defined to UID
99. It's defined unconditionally like this. To my knowledge there's no
actual use of this user at all in Fedora however. The UID 65514
carries no name by default on Fedora, but as soon as you install the
NFS utils it gets mapped to the "nfsnobody" user name, misleadingly
indicating that it would be used only by NFS even though it's a much
more general concept. I figure the NFS guys adopted the name
"nfsnobody" for this, simply because "nobody" was already taken by
UID
99 on Fedora, unlike on other distributions.
In the context of user namespacing the UID 65534 appears a lot more
often as owner of various files. For example, if you turn on user
namespacing in typical container managers you'll notice that a ton of
files in /proc will then be owned by this user. Very confusingly, in a
container that includes the NFS utils all those files actually show up
as "nfsnobody"-owned now, even though there's no relation to NFS at all
for them.
I'd like to propose that we clean this up, and just make Fedora work
like all other distributions. After all the reason of having this
special UID in the first place is to sidestep mapping problems between
different UID "realms". Hence I think it would be wise to at least
make the name of this very special UID somewhat more stable and
well-defined between distributions.
I think this is of particular relevance as Debian/Ubuntu-based
container images tend to be substantially more popular than
Fedora-based ones, and hence I think we should try to unify at least
the names and semantics of the two special UIDs all distros have, to
minimize mapping problems and making user interaction in containers a
bit more friendly.
You might ask of course, why Fedora should change to adopt
Debian's/Ubuntu's definition, instead of conversely making them adopt
Fedora's definition? Well, that's simple: Debian's definition makes a
lot more sense than Fedora's. And nothing we ship actually makes use
of FEdora's definition afaics, and we currently carry a workaround
called "nfsnobody" in some cases to avoid having to fix this properly.
Another option would be to define an entirely new user name for 65534,
for example "void" or so. But quite frankly, that sounds like a
pointless bikeshedding excercise, and creates even more confusion,
balkanization and political hassles if you'd try to convince other
distros to adopt the same scheme too.
Hence, let's go for "nobody == 65534" on Fedora too! And let's unify
the various dsitributions a tiny bit more, on this specific aspect.
How could a transition look like? I figure new installs should get
"nobody" defined to 65534. Old installs should keep the old
definitions in place instead. The NFS packages should be updated to
not create the "nfsnobody" user if there's already another user mapped
to 65534 (maybe it already does that?). Of course it's not pretty if
old and new systems use different definitions for this user, but I
think it's not too much of a real-life issue, as most code that refers
to this group already does so by UID instead of name, simply because
the name is not stable across distributions.
Opinions?
Lennart
--
Lennart Poettering, Red Hat
8:22 a.m.
On Mon, Jul 18, 2016 at 8:39 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
Heya!
I'd like to start a discussion regarding the "nobody" user on Fedora,
and propose that we change its definition sooner or later. I am not
proposing a feature according to the feature process for this yet, but
my hope is that these discussions will lead to one eventually.
Most distributions (in particular Debian/Ubuntu-based ones) map the
user "nobody" to UID 65534. I think we should change Fedora to do the
same. Background:
On Linux two UIDs are special: that's UID 0 for root, which is the
privileged user we all know. And then there's UID 65534
(i.e. (uint16_t) -2), which is less well known. The Linux kernel calls
it the "overflow" UID. It has four purposes:
1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs
only supports 16bit UIDs, but a 32bit UID is passed to it.
2. it's used by the kernel's user namespacing as a the internal UID
that external UIDs are mapped to that don't have any local mapping.
3. It's used by NFS for all user IDs that cannot be mapped locally if
UID mapping is enabled.
4. One upon a time some system daemons chose to run as the "nobody"
user, instead of a proper system user of their own. But this is
universally frowned upon, and isn't done on any current systems
afaics. In fact, to my knowledge Fedora even prohibits this
explicitly in its policy (?).
The uses 1-3 are relevant today, use 4 is clearly obsolete
afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something
that cannot be mapped properly is mapped to".
On Fedora, we currently have a "nobody" user that is defined to UID
99. It's defined unconditionally like this. To my knowledge there's no
actual use of this user at all in Fedora however. The UID 65514
carries no name by default on Fedora, but as soon as you install the
NFS utils it gets mapped to the "nfsnobody" user name, misleadingly
indicating that it would be used only by NFS even though it's a much
more general concept. I figure the NFS guys adopted the name
"nfsnobody" for this, simply because "nobody" was already taken by
UID
99 on Fedora, unlike on other distributions.
In the context of user namespacing the UID 65534 appears a lot more
often as owner of various files. For example, if you turn on user
namespacing in typical container managers you'll notice that a ton of
files in /proc will then be owned by this user. Very confusingly, in a
container that includes the NFS utils all those files actually show up
as "nfsnobody"-owned now, even though there's no relation to NFS at all
for them.
I'd like to propose that we clean this up, and just make Fedora work
like all other distributions. After all the reason of having this
special UID in the first place is to sidestep mapping problems between
different UID "realms". Hence I think it would be wise to at least
make the name of this very special UID somewhat more stable and
well-defined between distributions.
I think this is of particular relevance as Debian/Ubuntu-based
container images tend to be substantially more popular than
Fedora-based ones, and hence I think we should try to unify at least
the names and semantics of the two special UIDs all distros have, to
minimize mapping problems and making user interaction in containers a
bit more friendly.
You might ask of course, why Fedora should change to adopt
Debian's/Ubuntu's definition, instead of conversely making them adopt
Fedora's definition? Well, that's simple: Debian's definition makes a
lot more sense than Fedora's. And nothing we ship actually makes use
of FEdora's definition afaics, and we currently carry a workaround
called "nfsnobody" in some cases to avoid having to fix this properly.
Another option would be to define an entirely new user name for 65534,
for example "void" or so. But quite frankly, that sounds like a
pointless bikeshedding excercise, and creates even more confusion,
balkanization and political hassles if you'd try to convince other
distros to adopt the same scheme too.
Hence, let's go for "nobody == 65534" on Fedora too! And let's unify
the various dsitributions a tiny bit more, on this specific aspect.
How could a transition look like? I figure new installs should get
"nobody" defined to 65534. Old installs should keep the old
definitions in place instead. The NFS packages should be updated to
not create the "nfsnobody" user if there's already another user mapped
to 65534 (maybe it already does that?). Of course it's not pretty if
old and new systems use different definitions for this user, but I
think it's not too much of a real-life issue, as most code that refers
to this group already does so by UID instead of name, simply because
the name is not stable across distributions.
Opinions?
Not an opinion but some useless but interesting facts: ubuntu as
Lennart mentions uses 65534 as nobody,
raub@desktop:/tmp$ id nobody
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
raub@desktop:/tmp$
but OSX uses a 32bit number (the topmost number):
bash-3.2$ id nobody
uid=4294967294(nobody) gid=4294967294(nobody)
groups=4294967294(nobody),402(com.apple.sharepoint.group.1),12(everyone),61(localaccounts)
bash-3.2$
Also, correct me if I am wrong but users created in freeipa has a
32bit uid (like AD?). It could be me, but I can see this same issue
being revisited in the future.
> Lennart
>
> --
> Lennart Poettering, Red Hat
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
8:59 a.m.
Lennart Poettering píše v Po 18. 07. 2016 v 14:39 +0200:
Heya!
I'd like to start a discussion regarding the "nobody" user on Fedora,
and propose that we change its definition sooner or later. I am not
proposing a feature according to the feature process for this yet, but
my hope is that these discussions will lead to one eventually.
Thanks for starting the discussion on Fedora devel - as there already
was https://bugzilla.redhat.com/show_bug.cgi?id=1350526 - where it ended
up closed NOTABUG - as the nfs-utils maintainer is concerned about such
change ( https://bugzilla.redhat.com/show_bug.cgi?id=1350526#c3 ) - and
most of commenters (moved across several components) recommended "not a
bug" resolution.
I agree with containers and user namespaces, overflow uid named
"nfsnobody" confuses users. But is there really some good and
non-disruptive solution? e.g. Overflow id can be changed to different
than (uint_16_t) -2, but it is the right way?
Most distributions (in particular Debian/Ubuntu-based ones) map the
user "nobody" to UID 65534. I think we should change Fedora to do the
same. Background:
On Linux two UIDs are special: that's UID 0 for root, which is the
privileged user we all know. And then there's UID 65534
(i.e. (uint16_t) -2), which is less well known. The Linux kernel calls
it the "overflow" UID. It has four purposes:
1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs
only supports 16bit UIDs, but a 32bit UID is passed to it.
2. it's used by the kernel's user namespacing as a the internal UID
that external UIDs are mapped to that don't have any local mapping.
3. It's used by NFS for all user IDs that cannot be mapped locally if
UID mapping is enabled.
4. One upon a time some system daemons chose to run as the "nobody"
user, instead of a proper system user of their own. But this is
universally frowned upon, and isn't done on any current systems
afaics. In fact, to my knowledge Fedora even prohibits this
explicitly in its policy (?).
The uses 1-3 are relevant today, use 4 is clearly obsolete
afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something
that cannot be mapped properly is mapped to".
On Fedora, we currently have a "nobody" user that is defined to UID
99. It's defined unconditionally like this. To my knowledge there's no
actual use of this user at all in Fedora however. The UID 65514
carries no name by default on Fedora, but as soon as you install the
NFS utils it gets mapped to the "nfsnobody" user name, misleadingly
indicating that it would be used only by NFS even though it's a much
more general concept. I figure the NFS guys adopted the name
"nfsnobody" for this, simply because "nobody" was already taken by
UID
99 on Fedora, unlike on other distributions.
It is really a historical reason. I don't think there was common
agreement at the time when 99 for nobody was selected (at least several
different approaches were in place these days).
In the context of user namespacing the UID 65534 appears a lot more
often as owner of various files. For example, if you turn on user
namespacing in typical container managers you'll notice that a ton of
files in /proc will then be owned by this user. Very confusingly, in a
container that includes the NFS utils all those files actually show up
as "nfsnobody"-owned now, even though there's no relation to NFS at all
for them.
I'd like to propose that we clean this up, and just make Fedora work
like all other distributions. After all the reason of having this
special UID in the first place is to sidestep mapping problems between
different UID "realms". Hence I think it would be wise to at least
make the name of this very special UID somewhat more stable and
well-defined between distributions.
I think this is of particular relevance as Debian/Ubuntu-based
container images tend to be substantially more popular than
Fedora-based ones, and hence I think we should try to unify at least
the names and semantics of the two special UIDs all distros have, to
minimize mapping problems and making user interaction in containers a
bit more friendly.
You might ask of course, why Fedora should change to adopt
Debian's/Ubuntu's definition, instead of conversely making them adopt
Fedora's definition? Well, that's simple: Debian's definition makes a
lot more sense than Fedora's. And nothing we ship actually makes use
of FEdora's definition afaics, and we currently carry a workaround
called "nfsnobody" in some cases to avoid having to fix this properly.
It is not just Fedora, ArchLinux uses 99 nobody as well - as far as I
know. And probably some other systems as well. Debian, Ubuntu and
OpenSUSE use 65534 (although OpenSUSE seems to use 65534:65533 to add
even more confusion)
Citing Wiki:
"Nobody: Historically, the user “nobody” was assigned UID -2 by several
operating systems, although other values such as 2^15−1 = 32,767 are
also in use, such as by OpenBSD ( http://gnats.netbsd.org/6594 ). For
compatibility between 16-bit and 32-bit UIDs, many Linux distributions
now set it to be 2^16−2 = 65,534; the Linux kernel defaults to returning
this value when a 32-bit UID does not fit into the return value of the
16-bit system calls ( http://lwn.net/Articles/532593/ ). An alternative
convention assigns the last UID of the range statically allocated for
system use (0-99) to nobody: 99."
Another option would be to define an entirely new user name for
65534,
for example "void" or so. But quite frankly, that sounds like a
pointless bikeshedding excercise, and creates even more confusion,
balkanization and political hassles if you'd try to convince other
distros to adopt the same scheme too.
Hence, let's go for "nobody == 65534" on Fedora too! And let's unify
the various dsitributions a tiny bit more, on this specific aspect.
And potentially break some scripts that rely either on "nfsnobody" or on
id. This is something where we don't have control over it.
How could a transition look like? I figure new installs should get
"nobody" defined to 65534. Old installs should keep the old
definitions in place instead. The NFS packages should be updated to
not create the "nfsnobody" user if there's already another user mapped
to 65534 (maybe it already does that?). Of course it's not pretty if
old and new systems use different definitions for this user, but I
think it's not too much of a real-life issue, as most code that refers
to this group already does so by UID instead of name, simply because
the name is not stable across distributions.
Opinions?
I agree having uid -2 named "nfsnobody" is just confusing with user
namespaces and containers - and we should find some way how to solve it.
I don't agree that changing 99 "nobody" to 65534 "nobody" in
default /etc/passwd and not using "nfsnobody" in default new nfs-utils
installations is the right way to solve the issue. It might be less
confusing for some users and more in sync with Debian (and less with
e.g. ArchLinux), but has the potential to break something and imho
brings only very low benefit.
Regards,
Ondrej
Lennart
9:28 a.m.
On Mon, 18.07.16 15:59, Ondřej Vašík (ovasik(a)redhat.com) wrote:
Lennart Poettering píše v Po 18. 07. 2016 v 14:39 +0200:
> Heya!
>
> I'd like to start a discussion regarding the "nobody" user on Fedora,
> and propose that we change its definition sooner or later. I am not
> proposing a feature according to the feature process for this yet, but
> my hope is that these discussions will lead to one eventually.
Thanks for starting the discussion on Fedora devel - as there already
was https://bugzilla.redhat.com/show_bug.cgi?id=1350526 - where it ended
up closed NOTABUG - as the nfs-utils maintainer is concerned about such
change ( https://bugzilla.redhat.com/show_bug.cgi?id=1350526#c3 ) - and
most of commenters (moved across several components) recommended "not a
bug" resolution.
I agree with containers and user namespaces, overflow uid named
"nfsnobody" confuses users. But is there really some good and
non-disruptive solution? e.g. Overflow id can be changed to different
than (uint_16_t) -2, but it is the right way?
Nah, why change it, that certainly would break more things than just
renaming the user name of it.
> Another option would be to define an entirely new user name for
65534,
> for example "void" or so. But quite frankly, that sounds like a
> pointless bikeshedding excercise, and creates even more confusion,
> balkanization and political hassles if you'd try to convince other
> distros to adopt the same scheme too.
>
> Hence, let's go for "nobody == 65534" on Fedora too! And let's
unify
> the various dsitributions a tiny bit more, on this specific aspect.
And potentially break some scripts that rely either on "nfsnobody" or on
id. This is something where we don't have control over it.
Well, we have a process in Fedora for implementing features: come up
with a reasonable strategy for a transition, implement it in Rawhide,
and rollback if it breaks too much stuff.
> How could a transition look like? I figure new installs should
get
> "nobody" defined to 65534. Old installs should keep the old
> definitions in place instead. The NFS packages should be updated to
> not create the "nfsnobody" user if there's already another user
mapped
> to 65534 (maybe it already does that?). Of course it's not pretty if
> old and new systems use different definitions for this user, but I
> think it's not too much of a real-life issue, as most code that refers
> to this group already does so by UID instead of name, simply because
> the name is not stable across distributions.
>
> Opinions?
I agree having uid -2 named "nfsnobody" is just confusing with user
namespaces and containers - and we should find some way how to solve it.
I don't agree that changing 99 "nobody" to 65534 "nobody" in
default /etc/passwd and not using "nfsnobody" in default new nfs-utils
installations is the right way to solve the issue. It might be less
confusing for some users and more in sync with Debian (and less with
e.g. ArchLinux), but has the potential to break something and imho
brings only very low benefit.
So what do you propose instead? Just stick our heads in the sand,
ignore the issue, accept that in containers all files in /proc now
sometimes show up as owned by the literal "65534" user and sometimes
as owned by "nfsnobody", depending on whether the NFS utils package is
in the mix or not, even though userns has really *nothing* to do with
NFS?
I mean, we can certainly stop developing Fedora, because of fear that
fixing things might break apps we never heard of that rely on a very
specific bug or misdesign in some very specific software. But I am not
convinced that fear-driven development is really the best strategy to
win the future...
Another option could be to simply define both name mappings in
/etc/passwd. i.e. list both the nfsnobody → 65534 mapping in it as
well as nobody → 65534. This is only semi-supported though, and might
just shift brokeness around... (a slightly different alternative could
be to implement the "nobody" mapping in an explicit NSS module that is
ordered after "files", and drop it from /etc/passwd. That way whatever
is defined in /etc/passwd would take precedence, but if "nobody" is
explicitly requested it would also be mapped, but would not show up in
the user listing of "getent passwd". In effect, /etc/passwd and
"getent passwd" would only show unique UID mappings that way, even
though "nobody" stays always resolvable).
Lennart
--
Lennart Poettering, Red Hat
10 a.m.
Lennart Poettering píše v Po 18. 07. 2016 v 16:28 +0200:
On Mon, 18.07.16 15:59, Ondřej Vašík (ovasik(a)redhat.com) wrote:
> Lennart Poettering píše v Po 18. 07. 2016 v 14:39 +0200:
> > Heya!
> >
> > I'd like to start a discussion regarding the "nobody" user on
Fedora,
> > and propose that we change its definition sooner or later. I am not
> > proposing a feature according to the feature process for this yet, but
> > my hope is that these discussions will lead to one eventually.
>
> Thanks for starting the discussion on Fedora devel - as there already
> was https://bugzilla.redhat.com/show_bug.cgi?id=1350526 - where it ended
> up closed NOTABUG - as the nfs-utils maintainer is concerned about such
> change ( https://bugzilla.redhat.com/show_bug.cgi?id=1350526#c3 ) - and
> most of commenters (moved across several components) recommended "not a
> bug" resolution.
>
> I agree with containers and user namespaces, overflow uid named
> "nfsnobody" confuses users. But is there really some good and
> non-disruptive solution? e.g. Overflow id can be changed to different
> than (uint_16_t) -2, but it is the right way?
Nah, why change it, that certainly would break more things than just
renaming the user name of it.
It is just other way of solving this issue. Nobody tried this, nobody
can say whether this will break more things than changing nobody to
different nobody ;).
> > Another option would be to define an entirely new user name
for 65534,
> > for example "void" or so. But quite frankly, that sounds like a
> > pointless bikeshedding excercise, and creates even more confusion,
> > balkanization and political hassles if you'd try to convince other
> > distros to adopt the same scheme too.
> >
> > Hence, let's go for "nobody == 65534" on Fedora too! And
let's unify
> > the various dsitributions a tiny bit more, on this specific aspect.
>
> And potentially break some scripts that rely either on "nfsnobody" or on
> id. This is something where we don't have control over it.
Well, we have a process in Fedora for implementing features: come up
with a reasonable strategy for a transition, implement it in Rawhide,
and rollback if it breaks too much stuff.
> > How could a transition look like? I figure new installs should get
> > "nobody" defined to 65534. Old installs should keep the old
> > definitions in place instead. The NFS packages should be updated to
> > not create the "nfsnobody" user if there's already another user
mapped
> > to 65534 (maybe it already does that?). Of course it's not pretty if
> > old and new systems use different definitions for this user, but I
> > think it's not too much of a real-life issue, as most code that refers
> > to this group already does so by UID instead of name, simply because
> > the name is not stable across distributions.
> >
> > Opinions?
>
> I agree having uid -2 named "nfsnobody" is just confusing with user
> namespaces and containers - and we should find some way how to solve it.
> I don't agree that changing 99 "nobody" to 65534 "nobody"
in
> default /etc/passwd and not using "nfsnobody" in default new nfs-utils
> installations is the right way to solve the issue. It might be less
> confusing for some users and more in sync with Debian (and less with
> e.g. ArchLinux), but has the potential to break something and imho
> brings only very low benefit.
So what do you propose instead? Just stick our heads in the sand,
ignore the issue, accept that in containers all files in /proc now
sometimes show up as owned by the literal "65534" user and sometimes
as owned by "nfsnobody", depending on whether the NFS utils package is
in the mix or not, even though userns has really *nothing* to do with
NFS?
No, that's not my proposal as you can read in my "we should find some
way how to solve it." ;)
I even proposed other way - changing overflowid/overflowgid
through /proc/sys/fs/overflowgid and /proc/sys/fs/overflowuid - that
should work - although changing documented defaults is usually not the
best way - so I don't think this is the right way to solve this either.
I mean, we can certainly stop developing Fedora, because of fear
that
fixing things might break apps we never heard of that rely on a very
specific bug or misdesign in some very specific software. But I am not
convinced that fear-driven development is really the best strategy to
win the future...
Another option could be to simply define both name mappings in
/etc/passwd. i.e. list both the nfsnobody → 65534 mapping in it as
well as nobody → 65534. This is only semi-supported though, and might
just shift brokeness around... (a slightly different alternative could
be to implement the "nobody" mapping in an explicit NSS module that is
ordered after "files", and drop it from /etc/passwd. That way whatever
is defined in /etc/passwd would take precedence, but if "nobody" is
explicitly requested it would also be mapped, but would not show up in
the user listing of "getent passwd". In effect, /etc/passwd and
"getent passwd" would only show unique UID mappings that way, even
though "nobody" stays always resolvable).
Mapping of both names to same ID through file precedence is not going to
solve this issue when nfs-utils package is installed. nfsnobody will own
some of the /proc files, confusing users. I like the NSS module a bit
more than "nobody->65534 , nfsnobody->get out" - especially if this will
be part of the systems where user namespaces are likely - to the
containers. Can be solution for most of the usecases (except the
container with nfs-utils installed).
In my opinion, simple solution is bad solution here. Maybe another
solution can be to define safe namespaces for system users - something
like _$name on OS X - however this is more complex than simple rename.
Regards,
Ondrej
Lennart
1:10 p.m.
On Mon, Jul 18, 2016 at 05:00:40PM +0200, Ondřej Vašík wrote:
Lennart Poettering píše v Po 18. 07. 2016 v 16:28 +0200:
> On Mon, 18.07.16 15:59, Ondřej Vašík (ovasik(a)redhat.com) wrote:
>
> > Lennart Poettering píše v Po 18. 07. 2016 v 14:39 +0200:
> > > Heya!
> > >
> > > I'd like to start a discussion regarding the "nobody" user
on Fedora,
> > > and propose that we change its definition sooner or later. I am not
> > > proposing a feature according to the feature process for this yet, but
> > > my hope is that these discussions will lead to one eventually.
> >
> > Thanks for starting the discussion on Fedora devel - as there already
> > was https://bugzilla.redhat.com/show_bug.cgi?id=1350526 - where it ended
> > up closed NOTABUG - as the nfs-utils maintainer is concerned about such
> > change ( https://bugzilla.redhat.com/show_bug.cgi?id=1350526#c3 ) - and
> > most of commenters (moved across several components) recommended "not a
> > bug" resolution.
> >
> > I agree with containers and user namespaces, overflow uid named
> > "nfsnobody" confuses users. But is there really some good and
> > non-disruptive solution? e.g. Overflow id can be changed to different
> > than (uint_16_t) -2, but it is the right way?
>
> Nah, why change it, that certainly would break more things than just
> renaming the user name of it.
It is just other way of solving this issue. Nobody tried this, nobody
can say whether this will break more things than changing nobody to
different nobody ;).
We can speculate what kind of breakage is possible when we do either
change:
If the numerical id of a user changes, files on disk there were
created under the old id will now be owned by a different user. If we
provide a compat name for the old numerical id, those files will show
under that user, and if we don't, it will show as the numerical
value. This is a cosmetic thing; what is more important is that if any
files on disk will become inaccessible. This means that we do not want
to change the numerical id for which any files exist. And I think
nfsnobody (or rather the overflow uid) falls into this category;
e.g. it is likely to inadvertently create such files by copying
something as root in a container.
OTOH, changing the name of a user has a different set of pitfalls:
anything referring to the old name will stop working. So simply changing
the name is not really an option.
Lennart Poettering píše v Po 18. 07. 2016 v 16:28 +0200:
> Another option could be to simply define both name mappings in
> /etc/passwd. i.e. list both the nfsnobody → 65534 mapping in it as
> well as nobody → 65534. This is only semi-supported though, and might
> just shift brokeness around...
IMHO this is the best option. Tools that read /etc/passwd stop at
the first matching entry, so 65534 will be resolved to nobody, and
nfsnobody will be resolved to 65534 as before. AFAIK, people have
used this trick to map multiple users to 0 for a long time, so it should
mostly work. I just did that change locally, and names are resolved properly,
pwck reports no errors. A potential pitfall could be other tools
which munge /etc/passwd or /etc/group getting confused. Enabling this
in rawhide should expose any if they exist.
> a slightly different alternative could
> be to implement the "nobody" mapping in an explicit NSS module that is
> ordered after "files"
The hard part will be inserting the module in the right place. This
is a similar problem as the (unsolved) issues with "hosts:" line. It
is hard to detect local modifications to nsswitch.conf, and impossible
to do any automatic change if any are detected.
My proposal: add
oldnobody:x:99:99:Old unmapped user:/:/sbin/nologin
nobody:x:65534:65534:Unmapped user:/:/sbin/nologin
nfsnobody:x:65534:65534:Unmapped User:/:/sbin/nologin
in /etc/passwd, and matching lines in /etc/group.
Let's do this statically in setup.rpm, and remove the manipulation
of nfsnobody from nfs-utils.rpm.
Zbyszek
4:58 a.m.
On Mon, 18.07.16 17:00, Ondřej Vašík (ovasik(a)redhat.com) wrote:
> So what do you propose instead? Just stick our heads in the
sand,
> ignore the issue, accept that in containers all files in /proc now
> sometimes show up as owned by the literal "65534" user and sometimes
> as owned by "nfsnobody", depending on whether the NFS utils package is
> in the mix or not, even though userns has really *nothing* to do with
> NFS?
No, that's not my proposal as you can read in my "we should find some
way how to solve it." ;)
I even proposed other way - changing overflowid/overflowgid
through /proc/sys/fs/overflowgid and /proc/sys/fs/overflowuid - that
should work - although changing documented defaults is usually not the
best way - so I don't think this is the right way to solve this
either.
I'd be be very careful with that, as this would mean files with the
old UIDs would suddenly change ownership, and code might lose access.
I am pretty sure that of the two bad solutions of changing the name of
the user or changing the UID of it, the latter is much worse than the
former...
> Another option could be to simply define both name mappings in
> /etc/passwd. i.e. list both the nfsnobody → 65534 mapping in it as
> well as nobody → 65534. This is only semi-supported though, and might
> just shift brokeness around... (a slightly different alternative could
> be to implement the "nobody" mapping in an explicit NSS module that is
> ordered after "files", and drop it from /etc/passwd. That way whatever
> is defined in /etc/passwd would take precedence, but if "nobody" is
> explicitly requested it would also be mapped, but would not show up in
> the user listing of "getent passwd". In effect, /etc/passwd and
> "getent passwd" would only show unique UID mappings that way, even
> though "nobody" stays always resolvable).
Mapping of both names to same ID through file precedence is not going to
solve this issue when nfs-utils package is installed. nfsnobody will own
some of the /proc files, confusing users. I like the NSS module a bit
more than "nobody->65534 , nfsnobody->get out" - especially if this will
be part of the systems where user namespaces are likely - to the
containers. Can be solution for most of the usecases (except the
container with nfs-utils installed).
The NSS option would work for me too. In fact, I am tempted to just
ship an NSS module along with systemd that maps UIDs 0 and 65534 like
this, if they aren't listed properly in /etc/passwd. Having that would
be pretty neat as container-like environments could drop their passwd
database entirely and still get useful resolution of the two most
relevant UIDs in this context.
In my opinion, simple solution is bad solution here. Maybe another
solution can be to define safe namespaces for system users - something
like _$name on OS X - however this is more complex than simple rename.
IIRC Debian adopted a similar scheme. Newly allocated system
users need to begin with an underscore. I am pretty sure Fedora should
adopt a similar scheme, at least for user/group names allocated from
now on... But that's a different discussion...
Lennart
--
Lennart Poettering, Red Hat
2:34 p.m.
On Mon, Jul 18, 2016 at 03:59:09PM +0200, Ondřej Vašík wrote:
Lennart Poettering píše v Po 18. 07. 2016 v 14:39 +0200:
> Heya!
>
> I'd like to start a discussion regarding the "nobody" user on Fedora,
> and propose that we change its definition sooner or later. I am not
> proposing a feature according to the feature process for this yet, but
> my hope is that these discussions will lead to one eventually.
Thanks for starting the discussion on Fedora devel - as there already
was https://bugzilla.redhat.com/show_bug.cgi?id=1350526 - where it ended
up closed NOTABUG - as the nfs-utils maintainer is concerned about such
change ( https://bugzilla.redhat.com/show_bug.cgi?id=1350526#c3 ) - and
most of commenters (moved across several components) recommended "not a
bug" resolution.
That was me. (I'm not the nfs-utils maintainer, though.)
I honestly didn't think about it much beyond: there might be some risk
to the change, so it needs some justification.
So, trying to think it through some more from an NFS point of view:
For authentication, rpc uses either numeric ID's or kerberos names.
For referring to principals in file owners, groups, or ACLs, NFSv2/v3
uses numeric ID's, NFSv4 may use string names instead in some cases.
So in the NFSv4 case you could end up with a read-modify-write of an ACL
resulting in on-disk references to uid 99 turning into 65534's.
That can happen in the local case too if, say, you're using a
commandline utility that uses names, and you map 99 and 65534 both to
"nobody" and "nobody" back to 65534.
NFS users can already see that sort of behavior in mixed-distro
environments.
Anyway, I don't know. It'd certainly be nice to see the current
situation cleaned up. I don't feel like I understand what might break
on transition.
--b.
>
> I agree with containers and user namespaces, overflow uid named
> "nfsnobody" confuses users. But is there really some good and
> non-disruptive solution? e.g. Overflow id can be changed to different
> than (uint_16_t) -2, but it is the right way?
>
> > Most distributions (in particular Debian/Ubuntu-based ones) map the
> > user "nobody" to UID 65534. I think we should change Fedora to do the
> > same. Background:
> >
> > On Linux two UIDs are special: that's UID 0 for root, which is the
> > privileged user we all know. And then there's UID 65534
> > (i.e. (uint16_t) -2), which is less well known. The Linux kernel calls
> > it the "overflow" UID. It has four purposes:
> >
> > 1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs
> > only supports 16bit UIDs, but a 32bit UID is passed to it.
> >
> > 2. it's used by the kernel's user namespacing as a the internal UID
> > that external UIDs are mapped to that don't have any local mapping.
> >
> > 3. It's used by NFS for all user IDs that cannot be mapped locally if
> > UID mapping is enabled.
> >
> > 4. One upon a time some system daemons chose to run as the "nobody"
> > user, instead of a proper system user of their own. But this is
> > universally frowned upon, and isn't done on any current systems
> > afaics. In fact, to my knowledge Fedora even prohibits this
> > explicitly in its policy (?).
> >
> > The uses 1-3 are relevant today, use 4 is clearly obsolete
> > afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something
> > that cannot be mapped properly is mapped to".
> >
> > On Fedora, we currently have a "nobody" user that is defined to UID
> > 99. It's defined unconditionally like this. To my knowledge there's no
> > actual use of this user at all in Fedora however. The UID 65514
> > carries no name by default on Fedora, but as soon as you install the
> > NFS utils it gets mapped to the "nfsnobody" user name, misleadingly
> > indicating that it would be used only by NFS even though it's a much
> > more general concept. I figure the NFS guys adopted the name
> > "nfsnobody" for this, simply because "nobody" was already
taken by UID
> > 99 on Fedora, unlike on other distributions.
>
> It is really a historical reason. I don't think there was common
> agreement at the time when 99 for nobody was selected (at least several
> different approaches were in place these days).
>
> > In the context of user namespacing the UID 65534 appears a lot more
> > often as owner of various files. For example, if you turn on user
> > namespacing in typical container managers you'll notice that a ton of
> > files in /proc will then be owned by this user. Very confusingly, in a
> > container that includes the NFS utils all those files actually show up
> > as "nfsnobody"-owned now, even though there's no relation to NFS
at all
> > for them.
> >
> > I'd like to propose that we clean this up, and just make Fedora work
> > like all other distributions. After all the reason of having this
> > special UID in the first place is to sidestep mapping problems between
> > different UID "realms". Hence I think it would be wise to at least
> > make the name of this very special UID somewhat more stable and
> > well-defined between distributions.
> >
> > I think this is of particular relevance as Debian/Ubuntu-based
> > container images tend to be substantially more popular than
> > Fedora-based ones, and hence I think we should try to unify at least
> > the names and semantics of the two special UIDs all distros have, to
> > minimize mapping problems and making user interaction in containers a
> > bit more friendly.
> >
> > You might ask of course, why Fedora should change to adopt
> > Debian's/Ubuntu's definition, instead of conversely making them adopt
> > Fedora's definition? Well, that's simple: Debian's definition makes
a
> > lot more sense than Fedora's. And nothing we ship actually makes use
> > of FEdora's definition afaics, and we currently carry a workaround
> > called "nfsnobody" in some cases to avoid having to fix this
properly.
>
> It is not just Fedora, ArchLinux uses 99 nobody as well - as far as I
> know. And probably some other systems as well. Debian, Ubuntu and
> OpenSUSE use 65534 (although OpenSUSE seems to use 65534:65533 to add
> even more confusion)
> Citing Wiki:
> "Nobody: Historically, the user “nobody” was assigned UID -2 by several
> operating systems, although other values such as 2^15−1 = 32,767 are
> also in use, such as by OpenBSD ( http://gnats.netbsd.org/6594 ). For
> compatibility between 16-bit and 32-bit UIDs, many Linux distributions
> now set it to be 2^16−2 = 65,534; the Linux kernel defaults to returning
> this value when a 32-bit UID does not fit into the return value of the
> 16-bit system calls ( http://lwn.net/Articles/532593/ ). An alternative
> convention assigns the last UID of the range statically allocated for
> system use (0-99) to nobody: 99."
>
>
>
> > Another option would be to define an entirely new user name for 65534,
> > for example "void" or so. But quite frankly, that sounds like a
> > pointless bikeshedding excercise, and creates even more confusion,
> > balkanization and political hassles if you'd try to convince other
> > distros to adopt the same scheme too.
> >
> > Hence, let's go for "nobody == 65534" on Fedora too! And let's
unify
> > the various dsitributions a tiny bit more, on this specific aspect.
>
> And potentially break some scripts that rely either on "nfsnobody" or on
> id. This is something where we don't have control over it.
>
> > How could a transition look like? I figure new installs should get
> > "nobody" defined to 65534. Old installs should keep the old
> > definitions in place instead. The NFS packages should be updated to
> > not create the "nfsnobody" user if there's already another user
mapped
> > to 65534 (maybe it already does that?). Of course it's not pretty if
> > old and new systems use different definitions for this user, but I
> > think it's not too much of a real-life issue, as most code that refers
> > to this group already does so by UID instead of name, simply because
> > the name is not stable across distributions.
> >
> > Opinions?
>
> I agree having uid -2 named "nfsnobody" is just confusing with user
> namespaces and containers - and we should find some way how to solve it.
> I don't agree that changing 99 "nobody" to 65534 "nobody" in
> default /etc/passwd and not using "nfsnobody" in default new nfs-utils
> installations is the right way to solve the issue. It might be less
> confusing for some users and more in sync with Debian (and less with
> e.g. ArchLinux), but has the potential to break something and imho
> brings only very low benefit.
>
> Regards,
> Ondrej
> >
> > Lennart
> >
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
9:18 a.m.
On 18 July 2016 at 08:39, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
Heya!
I'd like to start a discussion regarding the "nobody" user on Fedora,
and propose that we change its definition sooner or later. I am not
proposing a feature according to the feature process for this yet, but
my hope is that these discussions will lead to one eventually.
I am not against this proposal. It has been tried at least once before
in the past but those failed due to a lot of programs secretly relying
on the seperate uids and not a lot of people being able to fix it.
I am not 100% certain that it was mostly 99 due to issues with various
network authentication systems from long ago. (ypbind/ldap/etc) where
the MAX-2 UID was not assigned to nobody but some other system
account. I think this is why SUSE went with the range of uids because
MAX-1 -> MAX-16 was used in various OS's for a large amount of system
accounts.
That is from a time when the world was rules by UNIX and Linux was a
little thing. These days it is a different matter and we can try and
be more flexible. I would say that UID 99 is going to need to be set
to oldnobody or some such thing because of the upgraders versus fresh
installers and it will need to be kept that way for the eventual EL
branch.
--
Stephen J Smoogen.
2:23 p.m.
On Mon, Jul 18, 2016 at 10:18:49AM -0400, Stephen John Smoogen wrote:
> I'd like to start a discussion regarding the
"nobody" user on Fedora,
> and propose that we change its definition sooner or later. I am not
> proposing a feature according to the feature process for this yet, but
> my hope is that these discussions will lead to one eventually.
I am not against this proposal. It has been tried at least once before
in the past but those failed due to a lot of programs secretly relying
on the seperate uids and not a lot of people being able to fix it.
I am not 100% certain that it was mostly 99 due to issues with various
network authentication systems from long ago. (ypbind/ldap/etc) where
I remember when this came up before but can't find it now. I think it
was changed to 99 when UIDs went to 32 bit and it suddenly started
being 65535 on some systems and 4294967295 on others. * I was trying to
figure out why 99 was eventually chosen, but can't find it now.
In any case, the regularization makes sense to me.
* At $formeruniversity, we had someone who was trying to back up
/var/log without any special handling for sparse files and they
suddenly got very surprised and upset when lastlog became "gigantic".
Ah, good times.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:26 p.m.
On יום שלישי, 19 ביולי 2016 15:23:25 IDT Matthew Miller wrote:
...
I remember when this came up before but can't find it now. I think it
was changed to 99 when UIDs went to 32 bit and it suddenly started
being 65535 on some systems and 4294967295 on others. * I was trying to
figure out why 99 was eventually chosen, but can't find it now.
I believe the uid 99 come from trying not to overlap regular users.
Back then (end of 90's), regular users uid's were:
* On old RedHat Linux >= 500
* On some other Linux systems >= 1000
* On many legacy Unices >= 100 (except on Irix >= 1000)
It was very common to have NFS mounted /home across all servers (with different *NIX
vendors/versions).
So '99' was the "last" uid that was assured not to collide with
uid's of regular users on NFS.
--
Oron Peled Voice: +972-4-8228492
oron(a)actcom.co.il http://users.actcom.co.il/~oron
No, You Can't Have My Rights, I'm Still Using Them
4:17 p.m.
Oron Peled wrote:
On יום שלישי, 19 ביולי 2016 15:23:25 IDT Matthew Miller wrote:
> ...
> I remember when this came up before but can't find it now. I think it
> was changed to 99 when UIDs went to 32 bit and it suddenly started
> being 65535 on some systems and 4294967295 on others. * I was trying to
> figure out why 99 was eventually chosen, but can't find it now.
I believe the uid 99 come from trying not to overlap regular users.
Back then (end of 90's), regular users uid's were:
* On old RedHat Linux >= 500
* On some other Linux systems >= 1000
* On many legacy Unices >= 100 (except on Irix >= 1000)
It was very common to have NFS mounted /home across all servers (with different *NIX
vendors/versions).
So '99' was the "last" uid that was assured not to collide with
uid's of regular users on NFS.
Solaris and IRIX used to have 60001 as nobody, *and* either -2 or 65534
as nobody, either under the same name (!!!) or some alternative similar
to nfsnobody.
I don't think you want to assume that code thinks the two users are
really identical in practice or that it's safe to merge them, though.
-- Steve
--
Steven Bonneville <sbonnevi(a)redhat.com>
Technical Curriculum Architect
Red Hat | Red Hat Training Phone: +1-612-638-0507
gpg: 1024D/221D06FF 68B1 3E66 A351 6485 B9AF 24D8 3DF5 B50B 221D 06FF
4:45 p.m.
Lennart Poettering writes:
On Fedora, we currently have a "nobody" user that is
defined to UID
99. It's defined unconditionally like this. To my knowledge there's no
actual use of this user at all in Fedora however.
I see distccd running as the nobody user.
I also see dnsmasq running as the nobody user.
It is a very popular pastime to take a listening daemon and chroot-jail it
as the nobody user. I'm sure there's a bunch of other stuff in Fedora that
does this. These are just the ones running on my box.
It's unlikely that changing the nobody uid and gid will have any
regressions. However, it's not true that nothing uses nobody. nobody is
quite popular.
4:48 p.m.
On Mon, Jul 18, 2016 at 2:45 PM, Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
Lennart Poettering writes:
> On Fedora, we currently have a "nobody" user that is defined to UID
> 99. It's defined unconditionally like this. To my knowledge there's no
> actual use of this user at all in Fedora however.
I see distccd running as the nobody user.
I also see dnsmasq running as the nobody user.
This practice needs to end. For example, unless the offending code
uses a PID namespace, you can ptrace another 'nobody' process, steal
an fd pointing out of the chroot, and break out.
4:59 a.m.
On Mon, 18.07.16 17:45, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:
Lennart Poettering writes:
>On Fedora, we currently have a "nobody" user that is defined to UID
>99. It's defined unconditionally like this. To my knowledge there's no
>actual use of this user at all in Fedora however.
I see distccd running as the nobody user.
I also see dnsmasq running as the nobody user.
Urks, this looks broken. Don't our package guidelines prohibit this?
Lennart
--
Lennart Poettering, Red Hat
5:17 a.m.
On 19 July 2016 at 10:59, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Mon, 18.07.16 17:45, Sam Varshavchik (mrsam(a)courier-mta.com)
wrote:
> Lennart Poettering writes:
>
> >On Fedora, we currently have a "nobody" user that is defined to UID
> >99. It's defined unconditionally like this. To my knowledge there's no
> >actual use of this user at all in Fedora however.
>
> I see distccd running as the nobody user.
>
> I also see dnsmasq running as the nobody user.
Urks, this looks broken. Don't our package guidelines prohibit this?
I don't see anything in the overall guidelines[1], the users_and_groups
guidelines[2] or the systemd_unit guidelines[3]
A quick search of FPC tickets doesn't show any discussion there either.
[1] https://fedoraproject.org/wiki/Packaging:Guidelines
[2] https://fedoraproject.org/wiki/Packaging:UsersAndGroups
[3] https://fedoraproject.org/wiki/Packaging:Systemd
5:47 a.m.
On Tue, 19.07.16 11:17, James Hogarth (james.hogarth(a)gmail.com) wrote:
On 19 July 2016 at 10:59, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
> On Mon, 18.07.16 17:45, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:
>
> > Lennart Poettering writes:
> >
> > >On Fedora, we currently have a "nobody" user that is defined to
UID
> > >99. It's defined unconditionally like this. To my knowledge there's
no
> > >actual use of this user at all in Fedora however.
> >
> > I see distccd running as the nobody user.
> >
> > I also see dnsmasq running as the nobody user.
>
> Urks, this looks broken. Don't our package guidelines prohibit this?
>
>
>
I don't see anything in the overall guidelines[1], the users_and_groups
guidelines[2] or the systemd_unit guidelines[3]
A quick search of FPC tickets doesn't show any discussion there either.
[1] https://fedoraproject.org/wiki/Packaging:Guidelines
[2] https://fedoraproject.org/wiki/Packaging:UsersAndGroups
[3] https://fedoraproject.org/wiki/Packaging:Systemd
Hmm, OK. I filed an FPC ticket about this now:
https://fedorahosted.org/fpc/ticket/642
Lennart
--
Lennart Poettering, Red Hat
6:39 a.m.
On Mon, Jul 18, 2016 at 8:39 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Fedora, we currently have a "nobody" user that is
defined to UID
99. It's defined unconditionally like this. To my knowledge there's no
actual use of this user at all in Fedora however. The UID 65514
carries no name by default on Fedora, but as soon as you install the
NFS utils it gets mapped to the "nfsnobody" user name, misleadingly
indicating that it would be used only by NFS even though it's a much
more general concept. I figure the NFS guys adopted the name
"nfsnobody" for this, simply because "nobody" was already taken by
UID
99 on Fedora, unlike on other distributions.
At first glance it makes some sense. 2^32-2 doesn't force it into
64-bit space, it's tested on other operating systems, I'm concerned
that overlapping "nobody" with the working "nfsnobody" is going to
break tools. I'm also cncerned that it will change behavior for "tar",
"rsync", "star", and other programs that can be configured to store
and extract usernames *or* uids, or a mix of both.
In the context of user namespacing the UID 65534 appears a lot more
often as owner of various files. For example, if you turn on user
namespacing in typical container managers you'll notice that a ton of
files in /proc will then be owned by this user. Very confusingly, in a
container that includes the NFS utils all those files actually show up
as "nfsnobody"-owned now, even though there's no relation to NFS at all
for them.
And this is where the shift in behavior would get confusing.
How could a transition look like? I figure new installs should get
"nobody" defined to 65534. Old installs should keep the old
definitions in place instead. The NFS packages should be updated to
not create the "nfsnobody" user if there's already another user mapped
to 65534 (maybe it already does that?). Of course it's not pretty if
old and new systems use different definitions for this user, but I
think it's not too much of a real-life issue, as most code that refers
to this group already does so by UID instead of name, simply because
the name is not stable across distributions.
Like I said, I'm thinking of "rsync", "tar", and "star".
Also,
people.... do some interesting scripting to detect things like failed
NFS configurations. I'm not saying that's a blocker, but shifting it
to overlap with the current "nfsnobody" is likely to break some
people's tools in the field, especially if they run the latest Fedora
alongside RHEL, CentOS, or previous Fedora releases.
> Opinions?
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
11:55 a.m.
On Tue, 2016-07-19 at 07:39 -0400, Nico Kadel-Garcia wrote:
Like I said, I'm thinking of "rsync", "tar",
and "star". Also,
people.... do some interesting scripting to detect things like failed
NFS configurations. I'm not saying that's a blocker, but shifting it
to overlap with the current "nfsnobody" is likely to break some
people's tools in the field, especially if they run the latest Fedora
alongside RHEL, CentOS, or previous Fedora releases.
The breakage for some will be un-breakage for someone else, and being
consistent with the kernel point of view and other distributions, in
this case, is more important IMO.
Simo.
7:51 a.m.
New subject: Fixing the "nobody" user?
On 18 Jul 2016, at 8:39, Lennart Poettering wrote:
Heya!
I'd like to start a discussion regarding the "nobody" user on Fedora,
and propose that we change its definition sooner or later. I am not
proposing a feature according to the feature process for this yet, but
my hope is that these discussions will lead to one eventually.
Most distributions (in particular Debian/Ubuntu-based ones) map the
user "nobody" to UID 65534. I think we should change Fedora to do the
same. Background:
On Linux two UIDs are special: that's UID 0 for root, which is the
privileged user we all know. And then there's UID 65534
(i.e. (uint16_t) -2), which is less well known. The Linux kernel calls
it the "overflow" UID. It has four purposes:
1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs
only supports 16bit UIDs, but a 32bit UID is passed to it.
2. it's used by the kernel's user namespacing as a the internal UID
that external UIDs are mapped to that don't have any local mapping.
3. It's used by NFS for all user IDs that cannot be mapped locally if
UID mapping is enabled.
4. One upon a time some system daemons chose to run as the "nobody"
user, instead of a proper system user of their own. But this is
universally frowned upon, and isn't done on any current systems
afaics. In fact, to my knowledge Fedora even prohibits this
explicitly in its policy (?).
The uses 1-3 are relevant today, use 4 is clearly obsolete
afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something
that cannot be mapped properly is mapped to".
I think this is a good proposal, but the work would be in making sure use 4
really is obsolete since the big change here would be redefining what
that "nobody" means. Right now, "nobody" is a real local account that
scripts
and daemons have used to sandbox themselves, and sometimes we can even find
stuff like uid == 99 in conditionals.
It's important to NFS that when passing file owner name strings between
clients and servers the string "nobody" means the unmappable user, and not a
real user of lowest privilege. If we make the change to redefine what the
local user "nobody" means, we should make sure use 4 is obsolete.
Otherwise, NFS is pretty flexible about being able to configure uid/name
mappings, and I don't see a problem for NFS in changing -2 from nfsnobody to
nobody.
On Fedora, we currently have a "nobody" user that is
defined to UID
99. It's defined unconditionally like this. To my knowledge there's no
actual use of this user at all in Fedora however.
After a quick grep, Lustre has a
#define NOBODY_UID 99
I don't know how that's used..
The UID 65514 carries no name by default on Fedora, but as soon as
you
install the NFS utils it gets mapped to the "nfsnobody" user name,
misleadingly indicating that it would be used only by NFS even though it's
a much more general concept. I figure the NFS guys adopted the name
"nfsnobody" for this, simply because "nobody" was already taken by
UID 99
on Fedora, unlike on other distributions.
Likely, yes -- but maybe some of the other NFS people know more of the
history.
In the context of user namespacing the UID 65534 appears a lot more
often as owner of various files. For example, if you turn on user
namespacing in typical container managers you'll notice that a ton of
files in /proc will then be owned by this user. Very confusingly, in a
container that includes the NFS utils all those files actually show up
as "nfsnobody"-owned now, even though there's no relation to NFS at all
for them.
I'd like to propose that we clean this up, and just make Fedora work
like all other distributions. After all the reason of having this
special UID in the first place is to sidestep mapping problems between
different UID "realms". Hence I think it would be wise to at least
make the name of this very special UID somewhat more stable and
well-defined between distributions.
I think this is of particular relevance as Debian/Ubuntu-based
container images tend to be substantially more popular than
Fedora-based ones, and hence I think we should try to unify at least
the names and semantics of the two special UIDs all distros have, to
minimize mapping problems and making user interaction in containers a
bit more friendly.
You might ask of course, why Fedora should change to adopt
Debian's/Ubuntu's definition, instead of conversely making them adopt
Fedora's definition? Well, that's simple: Debian's definition makes a
lot more sense than Fedora's. And nothing we ship actually makes use
of FEdora's definition afaics, and we currently carry a workaround
called "nfsnobody" in some cases to avoid having to fix this properly.
Another option would be to define an entirely new user name for 65534,
for example "void" or so. But quite frankly, that sounds like a
pointless bikeshedding excercise, and creates even more confusion,
balkanization and political hassles if you'd try to convince other
distros to adopt the same scheme too.
Hence, let's go for "nobody == 65534" on Fedora too! And let's unify
the various dsitributions a tiny bit more, on this specific aspect.
How could a transition look like? I figure new installs should get
"nobody" defined to 65534. Old installs should keep the old
definitions in place instead. The NFS packages should be updated to
not create the "nfsnobody" user if there's already another user mapped
to 65534 (maybe it already does that?).
It should, since if nfsnobody does not exist it does:
/usr/sbin/useradd -l -c "Anonymous NFS User" -r -g 65534 -s /sbin/nologin -u
65534 -d /var/lib/nfs nfsnobody
.. which should fail with "useradd: UID 65534 is not unique"..
Ben
> Of course it's not pretty if old and new systems use different definitions
> for this user, but I think it's not too much of a real-life issue, as most
> code that refers to this group already does so by UID instead of name,
> simply because the name is not stable across distributions.
>
> Opinions?
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
11:52 a.m.
On Mon, 2016-07-18 at 14:39 +0200, Lennart Poettering wrote:
Heya!
I'd like to start a discussion regarding the "nobody" user on Fedora,
and propose that we change its definition sooner or later. I am not
proposing a feature according to the feature process for this yet,
but
my hope is that these discussions will lead to one eventually.
Most distributions (in particular Debian/Ubuntu-based ones) map the
user "nobody" to UID 65534. I think we should change Fedora to do the
same. Background:
On Linux two UIDs are special: that's UID 0 for root, which is the
privileged user we all know. And then there's UID 65534
(i.e. (uint16_t) -2), which is less well known. The Linux kernel
calls
it the "overflow" UID. It has four purposes:
1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs
only supports 16bit UIDs, but a 32bit UID is passed to it.
2. it's used by the kernel's user namespacing as a the internal UID
that external UIDs are mapped to that don't have any local
mapping.
3. It's used by NFS for all user IDs that cannot be mapped locally if
UID mapping is enabled.
4. One upon a time some system daemons chose to run as the "nobody"
user, instead of a proper system user of their own. But this is
universally frowned upon, and isn't done on any current systems
afaics. In fact, to my knowledge Fedora even prohibits this
explicitly in its policy (?).
The uses 1-3 are relevant today, use 4 is clearly obsolete
afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something
that cannot be mapped properly is mapped to".
On Fedora, we currently have a "nobody" user that is defined to UID
99. It's defined unconditionally like this. To my knowledge there's
no
actual use of this user at all in Fedora however. The UID 65514
carries no name by default on Fedora, but as soon as you install the
NFS utils it gets mapped to the "nfsnobody" user name, misleadingly
indicating that it would be used only by NFS even though it's a much
more general concept. I figure the NFS guys adopted the name
"nfsnobody" for this, simply because "nobody" was already taken by
UID
99 on Fedora, unlike on other distributions.
In the context of user namespacing the UID 65534 appears a lot more
often as owner of various files. For example, if you turn on user
namespacing in typical container managers you'll notice that a ton of
files in /proc will then be owned by this user. Very confusingly, in
a
container that includes the NFS utils all those files actually show
up
as "nfsnobody"-owned now, even though there's no relation to NFS at
all
for them.
I'd like to propose that we clean this up, and just make Fedora work
like all other distributions. After all the reason of having this
special UID in the first place is to sidestep mapping problems
between
different UID "realms". Hence I think it would be wise to at least
make the name of this very special UID somewhat more stable and
well-defined between distributions.
I think this is of particular relevance as Debian/Ubuntu-based
container images tend to be substantially more popular than
Fedora-based ones, and hence I think we should try to unify at least
the names and semantics of the two special UIDs all distros have, to
minimize mapping problems and making user interaction in containers a
bit more friendly.
You might ask of course, why Fedora should change to adopt
Debian's/Ubuntu's definition, instead of conversely making them adopt
Fedora's definition? Well, that's simple: Debian's definition makes a
lot more sense than Fedora's. And nothing we ship actually makes use
of FEdora's definition afaics, and we currently carry a workaround
called "nfsnobody" in some cases to avoid having to fix this
properly.
Another option would be to define an entirely new user name for
65534,
for example "void" or so. But quite frankly, that sounds like a
pointless bikeshedding excercise, and creates even more confusion,
balkanization and political hassles if you'd try to convince other
distros to adopt the same scheme too.
Hence, let's go for "nobody == 65534" on Fedora too! And let's unify
the various dsitributions a tiny bit more, on this specific aspect.
How could a transition look like? I figure new installs should get
"nobody" defined to 65534. Old installs should keep the old
definitions in place instead. The NFS packages should be updated to
not create the "nfsnobody" user if there's already another user
mapped
to 65534 (maybe it already does that?). Of course it's not pretty if
old and new systems use different definitions for this user, but I
think it's not too much of a real-life issue, as most code that
refers
to this group already does so by UID instead of name, simply because
the name is not stable across distributions.
Opinions?
+1,
Simo.
2888
days inactive
2890
days old
20 comments
15 participants
participants (15)
-
Andrew Lutomirski -
Benjamin Coddington -
J. Bruce Fields -
James Hogarth -
Lennart Poettering -
Matthew Miller -
Mauricio Tavares -
Nico Kadel-Garcia -
Ondřej Vašík -
Oron Peled -
Sam Varshavchik -
Simo Sorce -
Stephen John Smoogen -
Steve Bonneville -
Zbigniew Jędrzejewski-Szmek