On Thu, Jan 11, 2018 at 10:26:19AM +0000, James Hogarth wrote: > On 11 January 2018 at 01:41, Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: > > On Wed, Jan 10, 2018 at 10:26:24AM -0500, Nico Kadel-Garcia wrote: > >> On Wed, Jan 10, 2018 at 6:18 AM, Zbigniew Jędrzejewski-Szmek > >> <zbys...@in.waw.pl> wrote: > >> > On Wed, Jan 10, 2018 at 11:56:46AM +0100, Reindl Harald wrote: > >> >> > >> >> Am 10.01.2018 um 11:46 schrieb Jan Kurik: > >> >> >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 > >> >> that don't make updates easier but breaks existing setups where > >> >> nobody:nobody with 99:99 already owns files - don't touch long years > >> >> running machines due dist-upgrades please - at least not with "dnf > >> >> --releasever=28 distro-sync" > >> > > >> > That'd amount to leaving existing systems unchanged. That's an option > >> > that I didn't like and initially rejected, but yeah, it's probably > >> > better. > >> > I'll wait a bit more for feedback and update the proposal a bit later > >> > to leave existing systems alone (i.e. systems which have either nobody > >> > or nfsnobody already defined in the old style). > >> > > >> > Zbyszek > >> > >> This is particularly relevant for rsync or tar restorations from old > >> backups, and to NFS shares exposed across old and new environments. > >> It's why changing active uid and and gid for any account can be > >> perniciously awkward. > > > > Based on this and other feedback, we updated the proposal. > > We discussed all the ways in which we could try to reliably determine > > if "nobody" is actually used, but that seems impossible. So the updated > > version is: > > > > 1. update setup.rpm to nobody=65534 on new systems > > 2. teach systemd to not provide any mapping for nobody (in PID1 and in > > nss-systemd) based on a flag file, and create this file in %post if > > either nobody=99 or nfsnobody users are defined. > > > > This essentially means that existing systems would behave as before, > > and new systems will have just one nobody user with uid=65534. > > > > See https://fedoraproject.org/wiki/Changes/RenameNobodyUser for more > > detailed description. > > > > > I know this may sound fairly nasty in terms of work required to agree > a solution but I honestly have a strong dislike to taking this > approach. > > Having upgraded and freshly installed systems so different is going to > be messy with supporting users and in many deployed environments... > and it's not even about F26 and F27 -> F28 but what happens on an F29+ > system? > > Is this workaround going to be maintained in perpetuity? Is it just > going to cause even more confusion then? > > As a very simple example take a docker host that has been upgraded > with a fresh container on it. The nobody user is going to differ > between the two which will at a minimum cause confusion, if not actual > issues to arise.
This example is very unconvincing. If I have three docker images, one with Fedora, one with Ubuntu, one with OpenSUSE, I'll have different nobody user/group combo in each case. So expecting any sort of consistency is unwarranted already. > Sometimes you just need to "bite the bullet" on a change and accept it > will be painful in the short term for benefit in the longer term. Yeah, but "biting the bullet" is quite hard in this case. Somebody elsewhere in the thread raised the case of tarred backups. People expect to be able to restore files from a backup, always and unconditionally and without any owner misattribution. That's why we never remove existing users and setup.rpm does not reuse uids that stopped being useful 10 years ago. I expect that the workaround would have to be carried for quite a while, let's say two years, 4 releases. Hopefully by that time the use of the old names will be much rarer, and _then_ actually removing the workaround will be much easier. At the moment new systems stop having the old names defined by default, pressure starts on script/package/external-package to stop using those names. This means that their usually starts decreasing without anybody forcefully pushing that. I liked the original plan too, but I think there's too many (legitimate) concerns about breakage to push it through. If this was about one simple thing you need to check or do, then it'd be different, but finding all the uses of a user is messy and complicated. Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
