F28 System Wide Change: Rename "nobody" user

[Jan Kurik]

= System Wide Change: Rename "nobody" user =
https://fedoraproject.org/wiki/Changes/RenameNobodyUser

Change owner(s):
*Zbigniew Jędrzejewski-Szmek <zbyszek AT in DOT waw DOT pl>
* Lennart Poettering <lpoetter AT redhat DOT com>

Use "nobody:nobody" as the names for the kernel overflow UID:GID pair,
and retire the old "nfsnobody" name and the old "nobody:nogroup" pair
with 99:99 numbers


== Detailed Description ==
Status quo: Fedora statically defines "nobody:nobody" pair with
uid:gid of 99:99 in setup.rpm, and "nfsnobody:nfsnobody" pair with
uid:gid of 65534:65534 in nfs-utils.rpm.

This is problematic in a few different ways:
* 65534:65534 is used by the kernel as the overflow identifier, when
some UID cannot be represented in the current namespace. This applies
to both NFS, but probably more commonly nowadays to UIDs outside of
the current user namespace (e.g. when a file or process owned by a
user from outside of a container). Calling this "nfsnobody" is
misleading.
* the name for the overflow user is only defined when nfs-utils.rpm is
installed. In particular in containers people want to minimize the
number of packages installed, so nfs-utils is likely not to be
installed.
* the static nobody:nobody user/group pair was used for various
services for which weren't "worthy" of creating a dedicated user. This
is a severely misguided concept, because all processes of the nobody
user can ptrace and otherwise interact with each other. Separate users
for each service should be used instead, either normal allocated users
or systemd's DynamicUser's.
* other distributions use either nobody:nobody or nobody:nogroup for
the overflow uid:gid pair, and the different naming in Fedora is
confusing and can lead to incorrect use.

We propose to:
* stop using nfsnobody for the overflow uid/gid names
* stop using nobody for the static user 99 and group 99
* use the nobody:nobody pair of names for 65534:65534

On existing systems, to make upgrades easier:
* if nfsnobody was defined, keep it in /etc/passwd *after* the new
line for nobody:nobody, so that both the old name and the new name map
to the same numbers
* if nobody user or group with number 99 was defined, keep it in
/etc/passwd and /etc/group, but rename to _nobody

The new mapping for nobody:nobody would be implemented in two redundant ways:
* as a static allocation in /etc/passwd and /etc/group managed by setup.rpm
* dynamically provided by the nss-systemd module (by compiling systemd
with -Dnobody-user=nobody -Dnobody-group=nobody).



== Scope ==
* Proposal owners:
- recompile systemd with the right options to get expected answer from
nss-systemd
- propose patches for setup.rpm to add the new mapping and do the
steps listed in Detailed Description on update
- propose patches for nfs-utils to remove the nfsnobody mapping and do
the steps listed in Detailed Description on update

* Other developers:
watch for regressions

* Release engineering:
#7258: https://pagure.io/releng/issue/7258

* List of deliverables:
N/A

* Policies and guidelines:
nothing
(https://fedoraproject.org/wiki/Packaging:Guidelines#Users_and_Groups
already says "Note that system services packaged for Fedora MUST NOT
run as the nobody user" so no changes are required there.)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

[Neal Gompa]

On Wed, Jan 10, 2018 at 5:46 AM, Jan Kurik <jkurik(a)redhat.com&gt; wrote:
>  = System Wide Change: Rename "nobody" user =
>  https://fedoraproject.org/wiki/Changes/RenameNobodyUser
>
>  Change owner(s):
>  *Zbigniew Jędrzejewski-Szmek <zbyszek AT in DOT waw DOT pl>
>  * Lennart Poettering <lpoetter AT redhat DOT com>
>
>  Use "nobody:nobody" as the names for the kernel overflow UID:GID pair,
>  and retire the old "nfsnobody" name and the old "nobody:nogroup"
> pair
>  with 99:99 numbers
>
>
>  == Detailed Description ==
>  Status quo: Fedora statically defines "nobody:nobody" pair with
>  uid:gid of 99:99 in setup.rpm, and "nfsnobody:nfsnobody" pair with
>  uid:gid of 65534:65534 in nfs-utils.rpm.
>
>  This is problematic in a few different ways:
>  * 65534:65534 is used by the kernel as the overflow identifier, when
>  some UID cannot be represented in the current namespace. This applies
>  to both NFS, but probably more commonly nowadays to UIDs outside of
>  the current user namespace (e.g. when a file or process owned by a
>  user from outside of a container). Calling this "nfsnobody" is
>  misleading.
>  * the name for the overflow user is only defined when nfs-utils.rpm is
>  installed. In particular in containers people want to minimize the
>  number of packages installed, so nfs-utils is likely not to be
>  installed.
>  * the static nobody:nobody user/group pair was used for various
>  services for which weren't "worthy" of creating a dedicated user. This
>  is a severely misguided concept, because all processes of the nobody
>  user can ptrace and otherwise interact with each other. Separate users
>  for each service should be used instead, either normal allocated users
>  or systemd's DynamicUser's.
>  * other distributions use either nobody:nobody or nobody:nogroup for
>  the overflow uid:gid pair, and the different naming in Fedora is
>  confusing and can lead to incorrect use.
>
>  We propose to:
>  * stop using nfsnobody for the overflow uid/gid names
>  * stop using nobody for the static user 99 and group 99
>  * use the nobody:nobody pair of names for 65534:65534
>
>  On existing systems, to make upgrades easier:
>  * if nfsnobody was defined, keep it in /etc/passwd *after* the new
>  line for nobody:nobody, so that both the old name and the new name map
>  to the same numbers
>  * if nobody user or group with number 99 was defined, keep it in
>  /etc/passwd and /etc/group, but rename to _nobody
>
>  The new mapping for nobody:nobody would be implemented in two redundant ways:
>  * as a static allocation in /etc/passwd and /etc/group managed by setup.rpm
>  * dynamically provided by the nss-systemd module (by compiling systemd
>  with -Dnobody-user=nobody -Dnobody-group=nobody).
>  
Two questions:

1. Why nobody:nobody instead of nobody:nogroup? I've seen the latter
in use in several distributions.
* For note, we use this in Mageia:
http://gitweb.mageia.org/software/setup/tree/group
* Debian and Ubuntu also define it this way.

2. For existing systems, would renaming the nobody:nobody user to
oldnobody:oldnobody work instead? The uid would be preserved, which
should keep the mapping sane, and it would make it more obvious that
it's old, rather than using weird underscores.

In general, I support this change because the two nobody users made
things confusing for me and many other people. Simplifying this would
also harmonize things with everyone else, which helps for portability
of things. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Stephen John Smoogen]

On 10 January 2018 at 08:50, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Wed, Jan 10, 2018 at 5:46 AM, Jan Kurik <jkurik(a)redhat.com&gt;
> wrote: 
....
> > The new mapping for nobody:nobody would be implemented in two
> redundant ways:
> > * as a static allocation in /etc/passwd and /etc/group managed by setup.rpm
> > * dynamically provided by the nss-systemd module (by compiling systemd
> > with -Dnobody-user=nobody -Dnobody-group=nobody).
> >
>
>  Two questions:
>
>  1. Why nobody:nobody instead of nobody:nogroup? I've seen the latter
>  in use in several distributions.
>  * For note, we use this in Mageia:
>  http://gitweb.mageia.org/software/setup/tree/group
>  * Debian and Ubuntu also define it this way.
>
>  2. For existing systems, would renaming the nobody:nobody user to
>  oldnobody:oldnobody work instead? The uid would be preserved, which
>  should keep the mapping sane, and it would make it more obvious that
>  it's old, rather than using weird underscores.
>
>  In general, I support this change because the two nobody users made
>  things confusing for me and many other people. Simplifying this would
>  also harmonize things with everyone else, which helps for portability
>  of things. :)
>
>  
I think all of the above would be good additions to this. Having dealt
with multiple large deployments where 99:99 caused different problems
but then were hard-coded into being fixed if something is Fedora/RHEL
based... a lot of people updating to F28+ would have problems... and a
lot of people update vs fresh install.

>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Stephen J Smoogen.

[Steve Dickson]

On 01/10/2018 11:14 AM, Stephen John Smoogen wrote:
>  On 10 January 2018 at 08:50, Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
> > On Wed, Jan 10, 2018 at 5:46 AM, Jan Kurik <jkurik(a)redhat.com&gt; wrote:
>  ....
> >> The new mapping for nobody:nobody would be implemented in two redundant ways:
> >> * as a static allocation in /etc/passwd and /etc/group managed by setup.rpm
> >> * dynamically provided by the nss-systemd module (by compiling systemd
> >> with -Dnobody-user=nobody -Dnobody-group=nobody).
> >>
> >
> > Two questions:
> >
> > 1. Why nobody:nobody instead of nobody:nogroup? I've seen the latter
> > in use in several distributions.
> > * For note, we use this in Mageia:
> > http://gitweb.mageia.org/software/setup/tree/group
> > * Debian and Ubuntu also define it this way.
> >
> > 2. For existing systems, would renaming the nobody:nobody user to
> > oldnobody:oldnobody work instead? The uid would be preserved, which
> > should keep the mapping sane, and it would make it more obvious that
> > it's old, rather than using weird underscores.
> >
> > In general, I support this change because the two nobody users made
> > things confusing for me and many other people. Simplifying this would
> > also harmonize things with everyone else, which helps for portability
> > of things. :)
> >
> >
>  
>  I think all of the above would be good additions to this. Having dealt
>  with multiple large deployments where 99:99 caused different problems
>  but then were hard-coded into being fixed if something is Fedora/RHEL
>  based... a lot of people updating to F28+ would have problems... and a
>  lot of people update vs fresh install. 
Your are correct... there will problems...
compatible problems with
mostly likely legacy servers... like f27?? ;-) 

steved.  
> 
>> --
>> 真実はいつも一つ！/ Always, there's only one truth!
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 
> 
>

[Matthew Miller]

On Wed, Jan 10, 2018 at 11:46:13AM +0100, Jan Kurik wrote:
>  Use "nobody:nobody" as the names for the kernel overflow
> UID:GID pair,
>  and retire the old "nfsnobody" name and the old "nobody:nogroup"
> pair
>  with 99:99 numbers 
See previous thread on this proposal from two years ago:

https://lists.fedoraproject.org/archives/list/[e-mail].o...

There's some good discussion there. I'm still in favor. 


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 10, 2018 at 10:21:32AM -0500, Matthew Miller wrote:
>  On Wed, Jan 10, 2018 at 11:46:13AM +0100, Jan Kurik wrote:
>  > Use "nobody:nobody" as the names for the kernel overflow UID:GID pair,
>  > and retire the old "nfsnobody" name and the old "nobody:nogroup"
> pair
>  > with 99:99 numbers
>  
>  See previous thread on this proposal from two years ago:
>  
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  
>  There's some good discussion there. I'm still in favor.  
Right. The same people participate in the discussion and the same
things are said. The funny thing is that not the same people are
always saying the same thing.

The situation got both more complicated (because of nss-systemd)
and simpler (because of the one concrete effect of that discussion,
i.e. FPC forbidding the use of "nobody").

I added this link to the Change page.

Zbyszek

[Steve Dickson]

WOW... Why do you guys keep picking on NFS?? :-)

On 01/10/2018 05:46 AM, Jan Kurik wrote:
>  = System Wide Change: Rename "nobody" user =
>  https://fedoraproject.org/wiki/Changes/RenameNobodyUser
>  
>  Change owner(s):
>  *Zbigniew Jędrzejewski-Szmek <zbyszek AT in DOT waw DOT pl>
>  * Lennart Poettering <lpoetter AT redhat DOT com>
>  
>  Use "nobody:nobody" as the names for the kernel overflow UID:GID pair,
>  and retire the old "nfsnobody" name and the old "nobody:nogroup"
> pair
>  with 99:99 numbers
>  
>  
>  == Detailed Description ==
>  Status quo: Fedora statically defines "nobody:nobody" pair with
>  uid:gid of 99:99 in setup.rpm, and "nfsnobody:nfsnobody" pair with
>  uid:gid of 65534:65534 in nfs-utils.rpm.
>  
>  This is problematic in a few different ways:
>  * 65534:65534 is used by the kernel as the overflow identifier, when
>  some UID cannot be represented in the current namespace. This applies
>  to both NFS, but probably more commonly nowadays to UIDs outside of
>  the current user namespace (e.g. when a file or process owned by a
>  user from outside of a container). Calling this "nfsnobody" is
>  misleading. 
Misleading to Whom??? -2 has been used since the 80's 
There has to be an uid/gid to map unknown uid/gid to. 

>  * the name for the overflow user is only defined when nfs-utils.rpm
> is
>  installed. In particular in containers people want to minimize the
>  number of packages installed, so nfs-utils is likely not to be
>  installed. 
So if the nfs-utils is not installed... the id/gid will not be created

>  * the static nobody:nobody user/group pair was used for various
>  services for which weren't "worthy" of creating a dedicated user. This
>  is a severely misguided concept, because all processes of the nobody
>  user can ptrace and otherwise interact with each other. Separate users
>  for each service should be used instead, either normal allocated users
>  or systemd's DynamicUser's.
>  * other distributions use either nobody:nobody or nobody:nogroup for
>  the overflow uid:gid pair, and the different naming in Fedora is
>  confusing and can lead to incorrect use. 
But the uid/gid are still -2. 

>  
>  We propose to:
>  * stop using nfsnobody for the overflow uid/gid names
>  * stop using nobody for the static user 99 and group 99
>  * use the nobody:nobody pair of names for 65534:65534 
What are you going to replace
it with?? When a server
gives a client a uid/gid that it does know about
the client has to uid/gid to map it to. Somebody has
to own the files.

>  
>  On existing systems, to make upgrades easier:
>  * if nfsnobody was defined, keep it in /etc/passwd *after* the new
>  line for nobody:nobody, so that both the old name and the new name map
>  to the same numbers
>  * if nobody user or group with number 99 was defined, keep it in
>  /etc/passwd and /etc/group, but rename to _nobody 
WHY??? What problem is this
solving?? 

>  
>  The new mapping for nobody:nobody would be implemented in two redundant ways:
>  * as a static allocation in /etc/passwd and /etc/group managed by setup.rpm
>  * dynamically provided by the nss-systemd module (by compiling systemd
>  with -Dnobody-user=nobody -Dnobody-group=nobody). 
Again... I have to ask why? What
problem is this solving.

>  
>  
>  
>  == Scope ==
>  * Proposal owners:
>  - recompile systemd with the right options to get expected answer from
>  nss-systemd
>  - propose patches for setup.rpm to add the new mapping and do the
>  steps listed in Detailed Description on update
>  - propose patches for nfs-utils to remove the nfsnobody mapping and do
>  the steps listed in Detailed Description on update
>  
>  * Other developers:
>  watch for regressions 
Watch out??? Expect! When start messing around with uid/gid
in
the NFS world... your going to break things... most likely
legacy worlds... 

This is a very bad idea... IMHO... 

steved.

> 
> * Release engineering:
> #7258: https://pagure.io/releng/issue/7258
> 
> * List of deliverables:
> N/A
> 
> * Policies and guidelines:
> nothing
> (https://fedoraproject.org/wiki/Packaging:Guidelines#Users_and_Groups
> already says "Note that system services packaged for Fedora MUST NOT
> run as the nobody user" so no changes are required there.)
> 
> * Trademark approval:
> N/A (not needed for this Change)
>

[Lennart Poettering]

On Do, 11.01.18 16:13, Steve Dickson (SteveD(a)RedHat.com) wrote:

>  > This is problematic in a few different ways:
>  > * 65534:65534 is used by the kernel as the overflow identifier, when
>  > some UID cannot be represented in the current namespace. This applies
>  > to both NFS, but probably more commonly nowadays to UIDs outside of
>  > the current user namespace (e.g. when a file or process owned by a
>  > user from outside of a container). Calling this "nfsnobody" is
>  > misleading.
>
>  Misleading to Whom??? -2 has been used since the 80's 
>  There has to be an uid/gid to map unknown uid/gid to. 
I hope you are aware that user id 65534 is used by user namespacing
(i.e. CLONE_NEWUSER) too, and in that context is probably much more
prominently visible to users than in the NFS context. The fact that
the user/group is called "nfsnobody" is quite misleading if most users
see it only in the user namespacing context which has zero
relationship to NFS.

(Also, "-2" is not 65534. Since kernel 2.4 uid_t is 32bit on
Linux. That means "-2" translates to 4294967294, and not 65534. And
given that uid_t is defined as unsigned type on Linux it's kind
strange to even bother with negative values for this, that just
confuses everybody, including apparently yourself...)

>  > * the name for the overflow user is only defined when
> nfs-utils.rpm is
>  > installed. In particular in containers people want to minimize the
>  > number of packages installed, so nfs-utils is likely not to be
>  > installed.
>  So if the nfs-utils is not installed... the id/gid will not be
>  created 
Yes, and that's one of the issues we are trying to fix: the UID/GID is
used prominently, in the context of userns, but it either shows up as
not registered at all currently, or is assigned to NFS which is really
misleading.

>  > We propose to:
>  > * stop using nfsnobody for the overflow uid/gid names
>  > * stop using nobody for the static user 99 and group 99
>  > * use the nobody:nobody pair of names for 65534:65534
>
>  What are you going to replace it with?? When a server
>  gives a client a uid/gid that it does know about
>  the client has to uid/gid to map it to. Somebody has
>  to own the files. 
We are not taking the concept of this user/group away. We are also not
taking the UID/GID assignment 65534 away, either. All we are doing is
assigning it a better name and do so unconditionally, independently of
whether nfsutils is installed or not, as the UID/GID 65534 has plenty
uses outside of NFS.

Lennart

-- 
Lennart Poettering, Red Hat

[R P Herrold]

On Thu, 11 Jan 2018, Lennart Poettering wrote:

>  We are not taking the concept of this user/group away. We are also
> not
>  taking the UID/GID assignment 65534 away, either. All we are doing is
>  assigning it a better name and do so unconditionally, independently of
>  whether nfsutils is installed or not, as the UID/GID 65534 has plenty
>  uses outside of NFS. 
fixing something well and extensively documented, to something 
'new and improved' in the face of a huge and unchangeable set 
of implementations (and third-party webbish documentation) 
that cannot be changed:

	RO media 

	off-line images
 
        backups
 
        iscsi targets
 
        NFS exports from third-party appliances
 
        interop in hetergoneous environments
 
        SMB

... is this really worth the effort?  All it does, like the 
XKCD 'N+1 standards' cartoon, is add one more 'standard' that 
cannot displace the incumbents and diverges from 'Unix' for 
an, at best, cosmetic reason, as you state:

	All we are doing is assigning it a better name ...

-- Russ herrold

[Lennart Poettering]

On Do, 11.01.18 17:36, R P Herrold (herrold(a)owlriver.com) wrote:

>  On Thu, 11 Jan 2018, Lennart Poettering wrote:
>  
>  > We are not taking the concept of this user/group away. We are also not
>  > taking the UID/GID assignment 65534 away, either. All we are doing is
>  > assigning it a better name and do so unconditionally, independently of
>  > whether nfsutils is installed or not, as the UID/GID 65534 has plenty
>  > uses outside of NFS.
>  
>  fixing something well and extensively documented, to something 
>  'new and improved' in the face of a huge and unchangeable set 
>  of implementations (and third-party webbish documentation) 
>  that cannot be changed:
>  
>  	RO media 
>  
>  	off-line images
>   
>          backups
>   
>          iscsi targets
>   
>          NFS exports from third-party appliances
>   
>          SMB 
This is just FUDing around... It's a call for never improving and
correcting systems, and if we subscribed to that we might as well stop
developing Fedora altogether.

I mean, let's not forget that by default the user 65534 has no name on
Fedora. Only people who install NFS will get a name "nfsnobody"
assigned currently. This means the UID is already differently set up
on various Fedora systems, and our goal is to correct this for the
future at least. Let me stress this: currently there's no clear rule
on the name at all on Fedora, sometimes you get the name "nfsnobody"
and sometimes you do not get any. If we now introduce a fixed name for
the future, then things aren't really getting worse, as the assignment
was never clear anyway. However, in the long run it *will* get better,
as the name in upcoming Fedora versions will then be stable and
defined unconditionally.

>          interop in hetergoneous environments 
This item particularly contradicts your own point. The "nfsnobody"
thing is a Fedoraism/Redhatism. Distributions all differ on what they
call the user/group, but more common is nobody:nobody or
nobody:nogroup.

Hence, there's no interop in heterogenous envs currently, we trying to
normalize this a bit, by introducing a stable, more sensible name that
is shared with at least some other distros too.

>  ... is this really worth the effort?  All it does, like the 
>  XKCD 'N+1 standards' cartoon, is add one more 'standard' that 
>  cannot displace the incumbents and diverges from 'Unix' for 
>  an, at best, cosmetic reason, as you state:
>  
>  	All we are doing is assigning it a better name ... 
Yeah, a name that makes more sense than the old one. A name that is
established unconditionally, and a name that might not be accepted by
*all* distros, but certainly by more and wouldn't be a
Fedoraism/Redhatism anymore...

Lennart

-- 
Lennart Poettering, Red Hat

[Chuck Anderson]

On Thu, Jan 11, 2018 at 11:24:56PM +0100, Lennart Poettering wrote:
>  I hope you are aware that user id 65534 is used by user namespacing
>  (i.e. CLONE_NEWUSER) too, and in that context is probably much more
>  prominently visible to users than in the NFS context. The fact that
>  the user/group is called "nfsnobody" is quite misleading if most users
>  see it only in the user namespacing context which has zero
>  relationship to NFS. 
Is there any security implication of re-using 65534 for user
namespacing, since NFS was using it before?  Why not assign a new uid
for user namespacing?

[Lennart Poettering]

On Do, 11.01.18 17:44, Chuck Anderson (cra(a)WPI.EDU) wrote:

>  On Thu, Jan 11, 2018 at 11:24:56PM +0100, Lennart Poettering wrote:
>  > I hope you are aware that user id 65534 is used by user namespacing
>  > (i.e. CLONE_NEWUSER) too, and in that context is probably much more
>  > prominently visible to users than in the NFS context. The fact that
>  > the user/group is called "nfsnobody" is quite misleading if most users
>  > see it only in the user namespacing context which has zero
>  > relationship to NFS.
>  
>  Is there any security implication of re-using 65534 for user
>  namespacing, since NFS was using it before?  Why not assign a new uid
>  for user namespacing? 
Too late for that, you should have brought that up years ago when
userns was first proposed for inclusion in the Linux kernel.

Also, semantically what NFS does with this and what userns does with
this is actually pretty much the same: it's the UID where unmappable
other UIDs are mapped to.

Lennart

-- 
Lennart Poettering, Red Hat

[Steve Dickson]

Instead of doing the blow by blow these threads
always turn into I'm just going jump to the point.

systemd wants to use uid 65534 and it can't because
NFS is using it. So instead of changing systemd needs
they want to change NFS potentially break all NFS 
environments. 

Is or isn't this what we are talking about without
all the bloviation to justify the change.

steved.

[Lennart Poettering]

On Fr, 12.01.18 07:20, Steve Dickson (SteveD(a)RedHat.com) wrote:

>  Instead of doing the blow by blow these threads
>  always turn into I'm just going jump to the point.
>  
>  systemd wants to use uid 65534 and it can't because
>  NFS is using it. So instead of changing systemd needs
>  they want to change NFS potentially break all NFS 
>  environments. 
This is really not helpful. Grow up.

User namespacing is a Linux kernel feature. It's most well known
consumers are probably Docker, and maybe flatpak/bubblewrap and LXC.

Neither Docker, nor flatpak/bubblewrap, nor LXC are systemd projects.

It's not systemd that came up with reusing 65534 for user
namespacing. It's kernel people:

        $ cat /proc/sys/kernel/overflowuid 
        65534

You know, if you want my personal opinion: I don't think user
namespaces are particularly well designed even. But it doesn't
matter what I think on that, because userns is there, it has been
introduced by Linux kernel people, it's widely used, and it's not
going to go away. And we should make the best of it.

>  Is or isn't this what we are talking about without
>  all the bloviation to justify the change. 
It really is not. You *really* should read up on what the Linux kernel
has been doing with user namespaces and how it started using the 65534
UID for that.

That UID long ceased to be Steve Dickson's private property, and it's
not systemd who took it away from you. It's evil evil kernel
hackers. Please complain to them.

Thank you very much,

Lennart

-- 
Lennart Poettering, Red Hat

[Benjamin Coddington]

On 12 Jan 2018, at 7:40, Lennart Poettering wrote:

>  On Fr, 12.01.18 07:20, Steve Dickson (SteveD(a)RedHat.com) wrote:
>
> > Instead of doing the blow by blow these threads
> > always turn into I'm just going jump to the point.
> >
> > systemd wants to use uid 65534 and it can't because
> > NFS is using it. So instead of changing systemd needs
> > they want to change NFS potentially break all NFS
> > environments.
>
>  This is really not helpful. Grow up. 
This directive is equally unhelpful.  Steve D is condensing and summarizing
his understanding of the case and his argument here so that we can more
easily get to the point of the issue without a lot of back-and-forth.  I
think that counts as grown-up behavior.  He's wrong about systemd, thanks
for correcting him.

>  User namespacing is a Linux kernel feature. It's most well known
>  consumers are probably Docker, and maybe flatpak/bubblewrap and LXC.
>
>  Neither Docker, nor flatpak/bubblewrap, nor LXC are systemd projects.
>
>  It's not systemd that came up with reusing 65534 for user
>  namespacing. It's kernel people:
>
>          $ cat /proc/sys/kernel/overflowuid
>          65534 
OK, so do we need to go back and revisit the bug attached to this change?
https://bugzilla.redhat.com/show_bug.cgi?id=1350526

That was closed with NOTABUG.

>  You know, if you want my personal opinion: I don't think user
>  namespaces are particularly well designed even. But it doesn't
>  matter what I think on that, because userns is there, it has been
>  introduced by Linux kernel people, it's widely used, and it's not
>  going to go away. And we should make the best of it. 
But that doesn't mean it can't be changed or updated.  Let's find the best
way and not throw out some of the options.

> > Is or isn't this what we are talking about without
> > all the bloviation to justify the change.
>
>  It really is not. You *really* should read up on what the Linux kernel
>  has been doing with user namespaces and how it started using the 65534
>  UID for that. 
Good point; once again, I think let's go back to the bug and work on this
problem there.  It is likely that re-opening that bug will get the matter
back in front of a number of people that originally decided it shouldn't be
changed.

>  That UID long ceased to be Steve Dickson's private property, and
> it's
>  not systemd who took it away from you. It's evil evil kernel
>  hackers. Please complain to them. 
Steve Dickson is advocating for a large community of NFS users that have
been building things with NFS for long before the userns stuff started
conflicting.  He's not arguing because he thinks that it is his private
property, he's rightly raising the alarm that this change risks regressions,
and he's saying that risk is very likely, and the scope is probably larger
than you might realize.  I don't think he's attacking systemd.

Ben

[Steve Dickson]

On 01/12/2018 07:40 AM, Lennart Poettering wrote:
>  On Fr, 12.01.18 07:20, Steve Dickson (SteveD(a)RedHat.com) wrote:
>  
> > Instead of doing the blow by blow these threads
> > always turn into I'm just going jump to the point.
> >
> > systemd wants to use uid 65534 and it can't because
> > NFS is using it. So instead of changing systemd needs
> > they want to change NFS potentially break all NFS 
> > environments.
>  
>  This is really not helpful. Grow up. 
sigh... 

>  
>  User namespacing is a Linux kernel feature. It's most well known
>  consumers are probably Docker, and maybe flatpak/bubblewrap and LXC. 
Well know for
how long?

>  
>  Neither Docker, nor flatpak/bubblewrap, nor LXC are systemd projects.
>  
>  It's not systemd that came up with reusing 65534 for user
>  namespacing. It's kernel people:
>  
>          $ cat /proc/sys/kernel/overflowuid 
>          65534 
How was that number chosen and why can't be changed?
 
>  
>  You know, if you want my personal opinion:  
I don't...

>  
> > Is or isn't this what we are talking about without
> > all the bloviation to justify the change.
>  
>  It really is not. You *really* should read up on what the Linux kernel
>  has been doing with user namespaces and how it started using the 65534
>  UID for that.
>  
>  That UID long ceased to be Steve Dickson's private property, and it's
>  not systemd who took it away from you. It's evil evil kernel
>  hackers. Please complain to them. 
more sigh... This attitude is so old and
unnecessary... sigh again... 

steved.

[Lennart Poettering]

On Fr, 12.01.18 09:28, Steve Dickson (SteveD(a)RedHat.com) wrote:

>  > User namespacing is a Linux kernel feature. It's most well
> known
>  > consumers are probably Docker, and maybe flatpak/bubblewrap and LXC.
>  Well know for how long? 
The commit adding user namespaces to the Linux kernel was in 2007. 11
years ago, in kernel 2.6.23.

>  > It's not systemd that came up with reusing 65534 for user
>  > namespacing. It's kernel people:
>  > 
>  >         $ cat /proc/sys/kernel/overflowuid 
>  >         65534
>  How was that number chosen and why can't be changed? 
It's conceptually the same thing: it's where UIDs are mapped that
cannot be mapped properly otherwise.

In theory you can change it by echoing something into sysctl, but
that's mostly theoretic, and not what the various consumers of userns
do.

And regardless, it's conceptually the same thing anyway, so it makes a
ton of sense to use the UID there for both NFS and userns
purposes. While I have my reservations about userns in general the
logic behind using that UID for this purpose is very clear to me and
makes sense as far as I can see.

>  > That UID long ceased to be Steve Dickson's private property,
> and it's
>  > not systemd who took it away from you. It's evil evil kernel
>  > hackers. Please complain to them.
>
>  more sigh... This attitude is so old and unnecessary... sigh again...  
Well, you turned this into a "I don't like systemd" thing, not me.

Lennart

-- 
Lennart Poettering, Red Hat

[Steve Dickson]

On 01/12/2018 09:47 AM, Lennart Poettering wrote:
>  On Fr, 12.01.18 09:28, Steve Dickson (SteveD(a)RedHat.com) wrote:
>  
> >> User namespacing is a Linux kernel feature. It's most well known
> >> consumers are probably Docker, and maybe flatpak/bubblewrap and LXC.
> > Well know for how long?
>  
>  The commit adding user namespaces to the Linux kernel was in 2007. 11
>  years ago, in kernel 2.6.23. 
Wow... we've been living this way a long time...
Seemly without any problems?
If that is the case then I really don't see a need for this change
that could potentially cause such havoc.
 
>  
> >> It's not systemd that came up with reusing 65534 for user
> >> namespacing. It's kernel people:
> >>
> >>         $ cat /proc/sys/kernel/overflowuid 
> >>         65534
> > How was that number chosen and why can't be changed?
>  
>  It's conceptually the same thing: it's where UIDs are mapped that
>  cannot be mapped properly otherwise. 
Right... I'm assuming this overflow almost
never happens
from looking at the code. 

>  
>  In theory you can change it by echoing something into sysctl, but
>  that's mostly theoretic, and not what the various consumers of userns
>  do. 
Understood.

>  
>  And regardless, it's conceptually the same thing anyway, so it makes a
>  ton of sense to use the UID there for both NFS and userns
>  purposes. While I have my reservations about userns in general the
>  logic behind using that UID for this purpose is very clear to me and
>  makes sense as far as I can see.
>   
So the problem trying to be solved is when the overflow uid/gid
are used (which is rarely), the owner of the file become 
nfsnobody which does not make any sense because it is on a local filesystem.

If this is the case, my I suggest that since the overflow uid/gid is 
basically an arbitrary value and easily changeable... Why not 
have some boot process echo '99' into /proc/sys/kernel/overflowuid 
which would match nicely to a uid/gid of a user named 'nobody'? 

steved.

[Daniel Walsh]

On 01/12/2018 10:41 AM, Steve Dickson wrote:
>  On 01/12/2018 09:47 AM, Lennart Poettering wrote:
> > On Fr, 12.01.18 09:28, Steve Dickson (SteveD(a)RedHat.com) wrote:
> >
> >>> User namespacing is a Linux kernel feature. It's most well known
> >>> consumers are probably Docker, and maybe flatpak/bubblewrap and LXC.
> >> Well know for how long?
> > The commit adding user namespaces to the Linux kernel was in 2007. 11
> > years ago, in kernel 2.6.23.
>  Wow... we've been living this way a long time... Seemly without any problems?
>  If that is the case then I really don't see a need for this change
>  that could potentially cause such havoc. 
Having this in the kernel and actually
anyone using it are two different 
things.  We are just beginning to finally use this now.
>    
> >>> It's not systemd that came up with reusing 65534 for user
> >>> namespacing. It's kernel people:
> >>>
> >>>          $ cat /proc/sys/kernel/overflowuid
> >>>          65534
> >> How was that number chosen and why can't be changed?
> > It's conceptually the same thing: it's where UIDs are mapped that
> > cannot be mapped properly otherwise.
>  Right... I'm assuming this overflow almost never happens
>  from looking at the code. 
Well in UserNamespace it happens all the time.  Basically
any Inode that 
is owned by a uid that is not mapped in the usernamespace will be 
reported as this UID.
> > In theory you can change it by echoing something into sysctl,
> but
> > that's mostly theoretic, and not what the various consumers of userns
> > do.
>  Understood.
>
> > And regardless, it's conceptually the same thing anyway, so it makes a
> > ton of sense to use the UID there for both NFS and userns
> > purposes. While I have my reservations about userns in general the
> > logic behind using that UID for this purpose is very clear to me and
> > makes sense as far as I can see.
> >
>  So the problem trying to be solved is when the overflow uid/gid
>  are used (which is rarely), the owner of the file become
>  nfsnobody which does not make any sense because it is on a local filesystem. 
It is
not rare.
>  If this is the case, my I suggest that since the overflow uid/gid is
>  basically an arbitrary value and easily changeable... Why not
>  have some boot process echo '99' into /proc/sys/kernel/overflowuid
>  which would match nicely to a uid/gid of a user named 'nobody'? 
You would
force everyone everwhere to make this change.
>  steved.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Steve Dickson]

On 01/12/2018 10:57 AM, Daniel Walsh wrote:
>  On 01/12/2018 10:41 AM, Steve Dickson wrote:
> >
> > On 01/12/2018 09:47 AM, Lennart Poettering wrote:
> >> On Fr, 12.01.18 09:28, Steve Dickson (SteveD(a)RedHat.com) wrote:
> >>
> >>>> User namespacing is a Linux kernel feature. It's most well known
> >>>> consumers are probably Docker, and maybe flatpak/bubblewrap and LXC.
> >>> Well know for how long?
> >> The commit adding user namespaces to the Linux kernel was in 2007. 11
> >> years ago, in kernel 2.6.23.
> > Wow... we've been living this way a long time... Seemly without any problems?
> > If that is the case then I really don't see a need for this change
> > that could potentially cause such havoc.
>  Having this in the kernel and actually anyone using it are two different things.  We are
> just beginning to finally use this now. 
Ah... this explains the exposure of
nfsnobody... 

So if its just beginning to be used... we can change the defaults... right? :-) 

> >  
> >>>> It's not systemd that came up with reusing 65534 for user
> >>>> namespacing. It's kernel people:
> >>>>
> >>>>          $ cat /proc/sys/kernel/overflowuid
> >>>>          65534
> >>> How was that number chosen and why can't be changed?
> >> It's conceptually the same thing: it's where UIDs are mapped that
> >> cannot be mapped properly otherwise.
> > Right... I'm assuming this overflow almost never happens
> > from looking at the code.
>  Well in UserNamespace it happens all the time.  Basically any Inode that is owned by a
> uid that is not mapped in the usernamespace will be reported as this UID. 
Ok...
understood.

> >> In theory you can change it by echoing something into sysctl,
> but
> >> that's mostly theoretic, and not what the various consumers of userns
> >> do.
> > Understood.
> >
> >> And regardless, it's conceptually the same thing anyway, so it makes a
> >> ton of sense to use the UID there for both NFS and userns
> >> purposes. While I have my reservations about userns in general the
> >> logic behind using that UID for this purpose is very clear to me and
> >> makes sense as far as I can see.
> >>
> > So the problem trying to be solved is when the overflow uid/gid
> > are used (which is rarely), the owner of the file become
> > nfsnobody which does not make any sense because it is on a local filesystem.
>  It is not rare.
> > If this is the case, my I suggest that since the overflow uid/gid is
> > basically an arbitrary value and easily changeable... Why not
> > have some boot process echo '99' into /proc/sys/kernel/overflowuid
> > which would match nicely to a uid/gid of a user named 'nobody'?
>  You would force everyone everwhere to make this change. 
If I'm understanding
your question... Yes this would be a fedora-only 
thing... but so what? We have a lot of Fedora only things.

Side Note: I have a ping out to a SUSE guy to see how they handle this
but the guy lives on the other side of the earth so I probably
will not get a response until tomorrow.

steved.

[Neal Gompa]

On Fri, Jan 12, 2018 at 11:19 AM, Steve Dickson <SteveD(a)redhat.com&gt; wrote:
>  On 01/12/2018 10:57 AM, Daniel Walsh wrote:
> > On 01/12/2018 10:41 AM, Steve Dickson wrote:
> >>
> >> On 01/12/2018 09:47 AM, Lennart Poettering wrote:
> >>> On Fr, 12.01.18 09:28, Steve Dickson (SteveD(a)RedHat.com) wrote:
> >>>
> >>>>> User namespacing is a Linux kernel feature. It's most well known
> >>>>> consumers are probably Docker, and maybe flatpak/bubblewrap and LXC.
> >>>> Well know for how long?
> >>> The commit adding user namespaces to the Linux kernel was in 2007. 11
> >>> years ago, in kernel 2.6.23.
> >> Wow... we've been living this way a long time... Seemly without any
> problems?
> >> If that is the case then I really don't see a need for this change
> >> that could potentially cause such havoc.
> > Having this in the kernel and actually anyone using it are two different things.  We
> are just beginning to finally use this now.
>  Ah... this explains the exposure of nfsnobody...
>
>  So if its just beginning to be used... we can change the defaults... right? :-)
>
> >>
> >>>>> It's not systemd that came up with reusing 65534 for user
> >>>>> namespacing. It's kernel people:
> >>>>>
> >>>>>          $ cat /proc/sys/kernel/overflowuid
> >>>>>          65534
> >>>> How was that number chosen and why can't be changed?
> >>> It's conceptually the same thing: it's where UIDs are mapped that
> >>> cannot be mapped properly otherwise.
> >> Right... I'm assuming this overflow almost never happens
> >> from looking at the code.
> > Well in UserNamespace it happens all the time.  Basically any Inode that is owned by
> a uid that is not mapped in the usernamespace will be reported as this UID.
>  Ok... understood.
>
> >>> In theory you can change it by echoing something into sysctl, but
> >>> that's mostly theoretic, and not what the various consumers of userns
> >>> do.
> >> Understood.
> >>
> >>> And regardless, it's conceptually the same thing anyway, so it makes a
> >>> ton of sense to use the UID there for both NFS and userns
> >>> purposes. While I have my reservations about userns in general the
> >>> logic behind using that UID for this purpose is very clear to me and
> >>> makes sense as far as I can see.
> >>>
> >> So the problem trying to be solved is when the overflow uid/gid
> >> are used (which is rarely), the owner of the file become
> >> nfsnobody which does not make any sense because it is on a local filesystem.
> > It is not rare.
> >> If this is the case, my I suggest that since the overflow uid/gid is
> >> basically an arbitrary value and easily changeable... Why not
> >> have some boot process echo '99' into /proc/sys/kernel/overflowuid
> >> which would match nicely to a uid/gid of a user named 'nobody'?
> > You would force everyone everwhere to make this change.
>  If I'm understanding your question... Yes this would be a fedora-only
>  thing... but so what? We have a lot of Fedora only things.
>
>  Side Note: I have a ping out to a SUSE guy to see how they handle this
>  but the guy lives on the other side of the earth so I probably
>  will not get a response until tomorrow. 
I can tell you what that is, as I run (open)SUSE systems.

SUSE systems set the following in their /etc/passwd:
nobody:x:65534:65533:nobody:/var/lib/nobody:/bin/bash

This is what they set for /etc/group:
nobody:x:65533:
nogroup:x:65534:nobody

This only varies slightly from what Mageia and Debian/Ubuntu do in
that nobody is both a member of nogroup but has its own nobody group.

-- 
真実はいつも一つ！/ Always, there's only one truth!

[Steve Dickson]

On 01/12/2018 05:11 PM, Neal Gompa wrote:
> > Side Note: I have a ping out to a SUSE guy to see how they handle
> this
> > but the guy lives on the other side of the earth so I probably
> > will not get a response until tomorrow.
>  I can tell you what that is, as I run (open)SUSE systems.
>  
>  SUSE systems set the following in their /etc/passwd:
>  nobody:x:65534:65533:nobody:/var/lib/nobody:/bin/bash
>  
>  This is what they set for /etc/group:
>  nobody:x:65533:
>  nogroup:x:65534:nobody
>  
>  This only varies slightly from what Mageia and Debian/Ubuntu do in
>  that nobody is both a member of nogroup but has its own nobody group. 
I too
verified the above but they also have this id mapping
in /etc/idmapd.conf
 [Mapping]
    nobody-user = nobody
    Nobody-Group = nobody

which is the glue to make the nobody id used.
We have these commented out, by default.

So I guess the next question is what the current
nobody id (25) used for and why does it exist?

steved.

[Steve Dickson]

On 01/13/2018 08:50 AM, Steve Dickson wrote:
>  So I guess the next question is what the current
>  nobody id (25) used for and why does it exist? 
Doing some research on this back in Aug 2001
nfsnobody was added to nfs-utils for the reasons stated in 
   https://bugzilla.redhat.com/show_bug.cgi?id=22685

Basically they were concern about changing the 
uid value of the current 'nobody' account.

Why? IDK... 

steved.

[Daniel Walsh]

On 01/13/2018 10:18 AM, Steve Dickson wrote:
>  On 01/13/2018 08:50 AM, Steve Dickson wrote:
> > So I guess the next question is what the current
> > nobody id (25) used for and why does it exist?
>  Doing some research on this back in Aug 2001
>  nfsnobody was added to nfs-utils for the reasons stated in
>      https://bugzilla.redhat.com/show_bug.cgi?id=22685
>
>  Basically they were concern about changing the
>  uid value of the current 'nobody' account.
>
>  Why? IDK...
>
>  steved.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 
It is good to see that 17 years later we are arguing about the same 
thing.  :^)

[Lennart Poettering]

On Fr, 12.01.18 10:41, Steve Dickson (SteveD(a)RedHat.com) wrote:

>  >>> It's not systemd that came up with reusing 65534 for
> user
>  >>> namespacing. It's kernel people:
>  >>>
>  >>>         $ cat /proc/sys/kernel/overflowuid 
>  >>>         65534
>  >> How was that number chosen and why can't be changed?
>  > 
>  > It's conceptually the same thing: it's where UIDs are mapped that
>  > cannot be mapped properly otherwise.
>
>  Right... I'm assuming this overflow almost never happens
>  from looking at the code. 
Nope, it happens *all* the time. Just look into /proc in a container
with user namespacing. You'll see that the majority of files there are
owned by 65534, as these files for security reasons are owned by the
root user of the host (and not the root user of the container), and
that user tends not to be mapped to the container, so that the
container cannot make changes to /proc.

If userns is used it's very hard to not see the UID 65534 popping up
all the time.

>  So the problem trying to be solved is when the overflow uid/gid
>  are used (which is rarely), the owner of the file become 
>  nfsnobody which does not make any sense because it is on a local filesystem.
>  
>  If this is the case, my I suggest that since the overflow uid/gid is 
>  basically an arbitrary value and easily changeable... Why not 
>  have some boot process echo '99' into /proc/sys/kernel/overflowuid 
>  which would match nicely to a uid/gid of a user named 'nobody'?  
Well, uh, because nobody does that. Also: why? It's conceptually the
same thing.

And sorry to bring this to you, but I figure the users of userns
(through all its incarnations in Docker, flatpak, bubblewrap, nspawn,
LXC, …) are much more numerous than the ones of NFS, and the mindshare
is probably with them. 

You appear to suggest that changing the name of user 65534 would
create mapping problems for NFS that didn't exist before. But that's
bogus, as these mapping problems always existed pretty badly, since
the name "nfsnobody" is a Fedoraism/Redhatism, and other distros tend
to use nobody:nogroup or nobody:nobody for that user, and hence you
have to deal with the differences with the naming anyway already, in
all your code. I mean, NFS is not a Fedora/Red Hat-only thing, is it?
And it's definitely our intention to improve on this, and just give up
on this Fedoraism/Redhatism, and moving to something more generic.

Lennart

-- 
Lennart Poettering, Red Hat

[Nico Kadel-Garcia]

On Fri, Jan 12, 2018 at 9:28 AM, Steve Dickson <SteveD(a)redhat.com&gt; wrote:
>  On 01/12/2018 07:40 AM, Lennart Poettering wrote:
> > On Fr, 12.01.18 07:20, Steve Dickson (SteveD(a)RedHat.com) wrote:
> >
> >> Instead of doing the blow by blow these threads
> >> always turn into I'm just going jump to the point.
> >>
> >> systemd wants to use uid 65534 and it can't because
> >> NFS is using it. So instead of changing systemd needs
> >> they want to change NFS potentially break all NFS
> >> environments.
> >
> > This is really not helpful. Grow up.
>  sigh... 
I thought you were being polite, Steve.

> > User namespacing is a Linux kernel feature. It's most well
> known
> > consumers are probably Docker, and maybe flatpak/bubblewrap and LXC. 
Lennart, the general problem of inconsistent uids and/or gids for the
same files is a problem with all shared file systems, whether they are
inconsistent for the same file system inside of docker, or via NFS or
CIFS or ZFS or any network based access, or for backup tools such as
tar and cp, and for replicating between systems with scp or rsync.
"User namespacing" is a particular approach to the underlying issue.


> > Neither Docker, nor flatpak/bubblewrap, nor LXC are systemd
> projects.
> >
> > It's not systemd that came up with reusing 65534 for user
> > namespacing. It's kernel people:
> >
> >         $ cat /proc/sys/kernel/overflowuid
> >         65534
>  How was that number chosen and why can't be changed? 
It's (2^16)- 2, to deal with filesystems with only 16 bits for uid. I
can understand wanting to stay away from 2^16 or (2^16) - 1, . It's
described at http://www.linux-admins.net/2010/09/all-you-need-to-know-about-procsys.html

> > You know, if you want my personal opinion:
>
>  I don't...
>
> >> Is or isn't this what we are talking about without
> >> all the bloviation to justify the change.
> >
> > It really is not. You *really* should read up on what the Linux kernel
> > has been doing with user namespaces and how it started using the 65534
> > UID for that.
> >
> > That UID long ceased to be Steve Dickson's private property, and it's
> > not systemd who took it away from you. It's evil evil kernel
> > hackers. Please complain to them.
>
>  more sigh... This attitude is so old and unnecessary... sigh again... 
I thought you were being quite reasonable. The idea that this has
anything to do with systemd is confusing to me.

> steved.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Louis Lagendijk]

On Fri, 2018-01-12 at 07:20 -0500, Steve Dickson wrote:
>  Instead of doing the blow by blow these threads
>  always turn into I'm just going jump to the point.
>  
>  systemd wants to use uid 65534 and it can't because
>  NFS is using it. So instead of changing systemd needs
>  they want to change NFS potentially break all NFS 
>  environments. 
>  
>  Is or isn't this what we are talking about without
>  all the bloviation to justify the change.
>  
>  steved. 
Breaking all NFS environments is a (way?) too strong statement. My file
server is running Freebsd and it uses 65534 as userid for default.
Freebsd however calls it nobody, go, figure.... Now for nfs this is
nowadays no problem anymore as we have the id-mapper. It now maps
between 99 and  65534 and will start to automagically map between 65534
and 65534. 
Are there any real world examples of files owned by nobody left on
Fedora?

I guess that other OSs/distributions use 65534 for nobody, so this
change would improve inter-operability with other environments.

LouisL

[Steve Dickson]

On 01/12/2018 07:32 PM, Louis Lagendijk wrote:
>  On Fri, 2018-01-12 at 07:20 -0500, Steve Dickson wrote:
> > Instead of doing the blow by blow these threads
> > always turn into I'm just going jump to the point.
> >
> > systemd wants to use uid 65534 and it can't because
> > NFS is using it. So instead of changing systemd needs
> > they want to change NFS potentially break all NFS 
> > environments. 
> >
> > Is or isn't this what we are talking about without
> > all the bloviation to justify the change.
> >
> > steved.
>  
>  Breaking all NFS environments is a (way?) too strong statement. My file
>  server is running Freebsd and it uses 65534 as userid for default.
>  Freebsd however calls it nobody, go, figure.... Now for nfs this is
>  nowadays no problem anymore as we have the id-mapper. It now maps
>  between 99 and  65534 and will start to automagically map between 65534
>  and 65534. 
>  Are there any real world examples of files owned by nobody left on
>  Fedora?
>  
>  I guess that other OSs/distributions use 65534 for nobody, so this
>  change would improve inter-operability with other environments. 
I was worried the
over-the-wire uid was going to change but at 
this point I have a better understanding of what is needed.

steved.

[Steve Dickson]

On 01/10/2018 05:46 AM, Jan Kurik wrote:
>  = System Wide Change: Rename "nobody" user =
>  https://fedoraproject.org/wiki/Changes/RenameNobodyUser 
A nit... The proposed
rename looks like:
    nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin

Now that this is going to be used for NFS, should the user information 
field be more generic? 

Because with NFS is not an overflow its a id mapping. Maybe just 'Kernel User'? 

Again... just an incredibly small nit! ;-) 

steved.

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 15, 2018 at 11:04:32AM -0500, Steve Dickson wrote:
>  
>  
>  On 01/10/2018 05:46 AM, Jan Kurik wrote:
>  > = System Wide Change: Rename "nobody" user =
>  > https://fedoraproject.org/wiki/Changes/RenameNobodyUser
>  A nit... The proposed rename looks like:
>      nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin
>  
>  Now that this is going to be used for NFS, should the user information 
>  field be more generic? 
>  
>  Because with NFS is not an overflow its a id mapping. Maybe just 'Kernel User'? 
>  
>  Again... just an incredibly small nit! ;-)  
Hmm, good point. Maybe "Kernel
Unmappable User" ?
nss-systemd in it's code currently uses "User Nobody", but that
doesn't explain anything, and I think that both pieces of
information are important to convey: that it is a kernel
concept, and that it is for overflow/unmapped users that are
hence anonymous.

Zbyszek

[Steve Dickson]

On 01/15/2018 01:28 PM, Zbigniew Jędrzejewski-Szmek wrote:
>  On Mon, Jan 15, 2018 at 11:04:32AM -0500, Steve Dickson wrote:
> >
> >
> > On 01/10/2018 05:46 AM, Jan Kurik wrote:
> >> = System Wide Change: Rename "nobody" user =
> >> https://fedoraproject.org/wiki/Changes/RenameNobodyUser
> > A nit... The proposed rename looks like:
> >     nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin
> >
> > Now that this is going to be used for NFS, should the user information 
> > field be more generic? 
> >
> > Because with NFS is not an overflow its a id mapping. Maybe just 'Kernel
> User'? 
> >
> > Again... just an incredibly small nit! ;-) 
>  Hmm, good point. Maybe "Kernel Unmappable User" ?
>  nss-systemd in it's code currently uses "User Nobody", but that
>  doesn't explain anything, and I think that both pieces of
>  information are important to convey: that it is a kernel
>  concept, and that it is for overflow/unmapped users that are
>  hence anonymous. 
"Kernel Unmappable User" works... IMHO.

steved.