Dear All, Can someone explain why there is such a difference in UID's as well as GUID's between leap 15 and Tumbleweed? I use multiple OSen, but all use the same data disks for none OS bounded data. For instance, I use one common data directory for use of Qemu with the group KVM. But under leap KVM is group 488 and under Tumbleweed 478, which makes it impossible to use the data sets without changing the GUID every time. This is just one example, there are many more. So, anyone...? Regards, Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Frans de Boer <frans@fransdb.nl> [06-08-18 06:59]:
Dear All,
Can someone explain why there is such a difference in UID's as well as GUID's between leap 15 and Tumbleweed?
I use multiple OSen, but all use the same data disks for none OS bounded data. For instance, I use one common data directory for use of Qemu with the group KVM. But under leap KVM is group 488 and under Tumbleweed 478, which makes it impossible to use the data sets without changing the GUID every time. This is just one example, there are many more.
iiuc, the levels are determined by the security level. look at yast -> security -> Miscellaneous Setting file permissions -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08-06-18 14:37, Patrick Shanahan wrote:
* Frans de Boer <frans@fransdb.nl> [06-08-18 06:59]:
Dear All,
Can someone explain why there is such a difference in UID's as well as GUID's between leap 15 and Tumbleweed?
I use multiple OSen, but all use the same data disks for none OS bounded data. For instance, I use one common data directory for use of Qemu with the group KVM. But under leap KVM is group 488 and under Tumbleweed 478, which makes it impossible to use the data sets without changing the GUID every time. This is just one example, there are many more.
iiuc, the levels are determined by the security level.
look at yast -> security -> Miscellaneous Setting file permissions
Sorry, that's not an answer I can use. I do not want to thinker with file permissions - I have them set to secure to disallow unauthorized users/processes. I just want consistency in (G/U)ID's across different distributions from the same source. Now I have to revert to renumbering the concerned (G/U)ID's to something in the 800 range to avoid constant 'chown -R :xxx <path>'. Yes, I hope that they keep away from that range so I can have my own fixed (G/U)ID's for special cases. btw, iiuc?? I speak English, not turbo "something". Regards, Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Frans de Boer <frans@fransdb.nl> [06-08-18 09:08]:
On 08-06-18 14:37, Patrick Shanahan wrote:
* Frans de Boer <frans@fransdb.nl> [06-08-18 06:59]:
Dear All,
Can someone explain why there is such a difference in UID's as well as GUID's between leap 15 and Tumbleweed?
I use multiple OSen, but all use the same data disks for none OS bounded data. For instance, I use one common data directory for use of Qemu with the group KVM. But under leap KVM is group 488 and under Tumbleweed 478, which makes it impossible to use the data sets without changing the GUID every time. This is just one example, there are many more.
iiuc, the levels are determined by the security level.
look at yast -> security -> Miscellaneous Setting file permissions
Sorry, that's not an answer I can use. I do not want to thinker with file permissions - I have them set to secure to disallow unauthorized users/processes. I just want consistency in (G/U)ID's across different distributions from the same source. Now I have to revert to renumbering the concerned (G/U)ID's to something in the 800 range to avoid constant 'chown -R :xxx <path>'. Yes, I hope that they keep away from that range so I can have my own fixed (G/U)ID's for special cases.
btw, iiuc?? I speak English, not turbo "something".
google it!
Regards, Frans.
you are certainly welcome -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-08 15:10, Patrick Shanahan wrote:
* Frans de Boer <> [06-08-18 09:08]:
On 08-06-18 14:37, Patrick Shanahan wrote:
* Frans de Boer <> [06-08-18 06:59]:
Dear All,
Can someone explain why there is such a difference in UID's as well as GUID's between leap 15 and Tumbleweed?
I use multiple OSen, but all use the same data disks for none OS bounded data. For instance, I use one common data directory for use of Qemu with the group KVM. But under leap KVM is group 488 and under Tumbleweed 478, which makes it impossible to use the data sets without changing the GUID every time. This is just one example, there are many more.
iiuc, the levels are determined by the security level.
look at yast -> security -> Miscellaneous Setting file permissions
Sorry, that's not an answer I can use. I do not want to thinker with file permissions - I have them set to secure to disallow unauthorized users/processes. I just want consistency in (G/U)ID's across different distributions from the same source. Now I have to revert to renumbering the concerned (G/U)ID's to something in the 800 range to avoid constant 'chown -R :xxx <path>'. Yes, I hope that they keep away from that range so I can have my own fixed (G/U)ID's for special cases.
btw, iiuc?? I speak English, not turbo "something".
google it!
No, IMO this question needs a dev that made that choice explaining it. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2018-06-08 15:10, Patrick Shanahan wrote:
* Frans de Boer <> [06-08-18 09:08]:
btw, iiuc?? I speak English, not turbo "something".
google it!
No, IMO this question needs a dev that made that choice explaining it.
Patrick meant "google iiuc". -- Per Jessen, Zürich (17.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-08 20:22, Per Jessen wrote:
Carlos E. R. wrote:
On 2018-06-08 15:10, Patrick Shanahan wrote:
* Frans de Boer <> [06-08-18 09:08]:
btw, iiuc?? I speak English, not turbo "something".
google it!
No, IMO this question needs a dev that made that choice explaining it.
Patrick meant "google iiuc".
Oops. cer@Telcontar:~> wtf iiuc IIUC: if I understand correctly cer@Telcontar:~> :-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/08/2018 01:22 PM, Per Jessen wrote:
Patrick meant "google iiuc".
I did, what the hell does "International Islamic University, Chittagong" have to do with anything? (chuckling....) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/06/18 06:57 AM, Frans de Boer wrote:
Can someone explain why there is such a difference in UID's as well as GUID's between leap 15 and Tumbleweed?
I presume that you have taken the /etc/passwd files from each, sorted them by UID and looked at them side by side? Then the same for the GID fields. sort -n -t ':' -k3 /etc/passwd sort -n -t ':' -k4 /etc/passwd Is that the basis for your observation and question? Disclaimer: I run neither Leap15 nor Tumbleweed. The reports I see here make me very apprehensive about using Leap15 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-08 12:57, Frans de Boer wrote:
Can someone explain why there is such a difference in UID's as well as GUID's between leap 15 and Tumbleweed?
Both UIDs and GIDs are in general dynamically allocated in the range set in /etc/login.defs. See the man pages for useradd and groupadd: -g, --gid GID The numerical value of the group's ID. This value must be unique, unless the -o option is used. The value must be non-negative. The default is to use the smallest ID value greater than or equal to GID_MIN and greater than every other group. Unless you prepare the users/groups with explicit IDs yourself, there is some kind of "randomness" involved during user/group creation when installing packages. You can change a UID/GID after the fact, but must also change ownership to the new ID across your file system. Something like groupmod --gid $NEWGID kvm find / -gid $OLDGID -exec chown :kvm {} + could work. Say, with NEWGID=488 and OLDID=478 on your Tumbleweed machine. Cheers -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-08 16:52, Christian Neyers wrote:
On 2018-06-08 12:57, Frans de Boer wrote:
Can someone explain why there is such a difference in UID's as well as GUID's between leap 15 and Tumbleweed?
Both UIDs and GIDs are in general dynamically allocated in the range set in /etc/login.defs.
That's my understanding as well. Unless the installer could be told to import an external /etc/passwd and /etc/group files. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/08/2018 12:01 PM, Carlos E. R. wrote:
That's my understanding as well.
Unless the installer could be told to import an external /etc/passwd and /etc/group files.
That's not correct for system UID/GID's. I agree for user UID/GID combos. User UID/GIDs are not necessarily semi-random, they generally start at 1000 on a first-come, first-served basis (some distros start the user range at 500). While the system UID/GIDs are distro/implementation defined to some extent -- they should always be consistent within a distribution between releases -- otherwise, that would break configs and applications. Requiring no end of user-interaction required to re-map the system UID/GID's to work with existing data on each new update. While there can/will always be new UID/GID's introduced by upstream changes (e.g. cups is a good recent example), as a rule, the distro should not remap, or semi-randomize system UID/GID between releases. Now TW is somewhat a different animal than Leap, so I suspect what happened is that as TW begin development, there wasn't any effort made to map the opensuse/Leap system UID/GID values and the devs just starting building somewhat of a new distro to become TW. By the time this issue became apparent, it was probably a bit too late to coordinate them again without a whole lot of effort. (they would be running into the same problems the original poster here did) -- David C. Rankin, J.D.,P.E.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2018-06-08 at 16:34 -0500, David C. Rankin wrote:
On 06/08/2018 12:01 PM, Carlos E. R. wrote:
That's my understanding as well.
Unless the installer could be told to import an external /etc/passwd and /etc/group files.
That's not correct for system UID/GID's. I agree for user UID/GID combos.
User UID/GIDs are not necessarily semi-random, they generally start at 1000 on a first-come, first-served basis (some distros start the user range at 500).
While the system UID/GIDs are distro/implementation defined to some extent -- they should always be consistent within a distribution between releases -- otherwise, that would break configs and applications. Requiring no end of user-interaction required to re-map the system UID/GID's to work with existing data on each new update.
No, they are not consistent at all: avahi:x:463:466:User for Avahi:/run/avah avahi:x:104:106:User for Avahi:/var/r dovecot:x:477:477:User for Dovecot imapd: dovecot:x:119:122:User for Dovecot imapd gdm:x:459:462:Gnome Display Manager dae gdm:x:50:109:Gnome Display Manager Left is my new laptop on 15.0 (passwd file), right is my old desktop machine on 42.3. Just three examples. The numbers are indeed random, there is no organization. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlszuFgACgkQtTMYHG2NR9Wc1wCfUP5tlwQj2adi9Kvyagk7N8Nf FPwAnjC0ywBGT7yezc6JIDuNWClCOhO+ =vnVc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, 27 June 2018 17:16:17 BST Carlos E. R. wrote:
User UID/GIDs are not necessarily semi-random, they generally start at 1000 on a first-come, first-served basis (some distros start the user range at 500).
While the system UID/GIDs are distro/implementation defined to some extent -- they should always be consistent within a distribution between releases -- otherwise, that would break configs and applications. Requiring no end of user-interaction required to re-map the system UID/GID's to work with existing data on each new update.
No, they are not consistent at all:
Worse than that when I created two cluster nodes on tumbleweed my qemu/ libvirt/kvm user uid and gid diddnt match across servers. It seems it is dependent on install order of software. I had groups and users defined on one server with specific uid/gid that didnt match on the users/groups on the other server with with same uids/gids -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
27.06.2018 23:54, Andrew Colvin пишет:
Worse than that when I created two cluster nodes on tumbleweed my qemu/ libvirt/kvm user uid and gid diddnt match across servers. It seems it is dependent on install order of software.
That's correct - users/groups are now created during package installation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/27/2018 03:54 PM, Andrew Colvin wrote:
Worse than that when I created two cluster nodes on tumbleweed my qemu/ libvirt/kvm user uid and gid diddnt match across servers. It seems it is dependent on install order of software. I had groups and users defined on one server with specific uid/gid that didnt match on the users/groups on the other server with with same uids/gids
You do know what it is called when it happens in a cluster -- right? "a cluster fu.." This is the epitome as to why you don't assign UID/GID on package install order... "I just installed several servers with Leap and the common configs I have don't work -- why?" How does this possibly help with security (or anything for that matter)? I guess people that do a one-off install of openSuSE will never know, but for those with multiple installs it does seem to impose some self-inflicted wounds. Does anybody know the actual reason behind why it is done this way? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi, all -- ...and then David C. Rankin said... % ... % This is the epitome as to why you don't assign UID/GID on package install order... % % "I just installed several servers with Leap and the common configs I have % don't work -- why?" [snip] Hear, hear! I know that it offends some sensibilities (mine included), but I just don't see a better method than carving off a range (eg 100-500) for system applications and assigning each in a SuSE central "registry" so that every single installation ends up with the same UIDs & GIDs -- and user and group *names*, too -- by default. We can't all connect to a master passwd & group service at SuSE when installing, and we obviously can't count on packages being installed in the same order every time, but we need structure. Since we don't want to have useless accounts on a system in this secure day and age and can't just preload all umpteen dozen accounts, build each package with the assignment of the proper account info so that it happens the same way every time. Apache httpd is always installed as apwww/143, nginx is always installed as nginx/144, mysql is always installed as mysqld/186, and so on, and the few who might have reason to deviate from that (versus the many who get screwed when things don't match) can do so easily enough. Just my twenty millibucks' worth... HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/28/2018 03:06 AM, David T-G wrote:
Hi, all --
...and then David C. Rankin said... % ... % This is the epitome as to why you don't assign UID/GID on package install order... % % "I just installed several servers with Leap and the common configs I have % don't work -- why?" [snip]
Hear, hear!
I know that it offends some sensibilities (mine included), but I just don't see a better method than carving off a range (eg 100-500) for system applications and assigning each in a SuSE central "registry" so that every single installation ends up with the same UIDs & GIDs -- and user and group *names*, too -- by default. We can't all connect to a master passwd & group service at SuSE when installing, and we obviously can't count on packages being installed in the same order every time, but we need structure.
Since we don't want to have useless accounts on a system in this secure day and age and can't just preload all umpteen dozen accounts, build each package with the assignment of the proper account info so that it happens the same way every time. Apache httpd is always installed as apwww/143, nginx is always installed as nginx/144, mysql is always installed as mysqld/186, and so on, and the few who might have reason to deviate from that (versus the many who get screwed when things don't match) can do so easily enough.
Just my twenty millibucks' worth...
HAND
:-D
The problem is bigger than just Opensuse. Not everybody is using the same Distro. RedHat has some standards, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/htm... So does Ubuntu https://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-opersys.... But they are far from complete. There probably aren't more packages competing for the 100-999 range than actual slots, but if there isn't today, there could be in the future. We could treat it like port numbers and kick the problem down the road a few decades. ;-) We might be able to have useless GIDs predefined. And there is no real problem with useless UIDs either as long as they can't log in, or even be used without root first doing so explicitly in some file somewhere. At least the allocation could/should be according to some list rather than just next available. Also getting a suggestion might be acquired via some akin to DNS. This USED to be in DNS as record types 101 and 102, but was obsoleted: https://en.wikipedia.org/wiki/List_of_DNS_record_types#Obsolete_record_types -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/28/2018 01:43 PM, John Andersen wrote:
The problem is bigger than just Opensuse. Not everybody is using the same Distro.
Being distro-defined is fine -- as long as the distro actually defines the UID/GID for core services. I expect to remap when moving between *distros*. I don't expect to have to remap moving between Leap 15 *installs*. It really seems like needless self-inflicted wound. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/28/2018 01:43 PM, John Andersen wrote:
The problem is bigger than just Opensuse. Not everybody is using the same Distro. Being distro-defined is fine -- as long as the distro actually defines the UID/GID for core services. I expect to remap when moving between *distros*. I don't expect to have to remap moving between Leap 15 *installs*.
It really seems like needless self-inflicted wound. Agreed and painful and one slip and the whole server gets screwed re-id-ing everything. I know I did it. Also makes my pxe build auto script more complex. I cant install the software as part of the autoyast - I have to control it and create the groups/users in the post install and then install
On Friday, 29 June 2018 09:12:07 BST David C. Rankin wrote: the software. The other option is to move all the UIDs and GIDs from local to LDAP... Really not happy with that or set up NIS. Corosync, shared drives, gluster all have issues if you do not fix uid/gids -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/27/2018 11:16 AM, Carlos E. R. wrote:
While the system UID/GIDs are distro/implementation defined to some extent -- they should always be consistent within a distribution between releases -- otherwise, that would break configs and applications. Requiring no end of user-interaction required to re-map the system UID/GID's to work with existing data on each new update.
No, they are not consistent at all:
avahi:x:463:466:User for Avahi:/run/avah avahi:x:104:106:User for Avahi:/var/r
dovecot:x:477:477:User for Dovecot imapd: dovecot:x:119:122:User for Dovecot imapd
gdm:x:459:462:Gnome Display Manager dae gdm:x:50:109:Gnome Display Manager
Left is my new laptop on 15.0 (passwd file), right is my old desktop machine on 42.3. Just three examples.
The numbers are indeed random, there is no organization.
That does pose a problem for an rsync or cp -a move of configs from 42.3 to 15. Unless there is some SuSEConfig mapping somewhere remapping behind the scenes (which I've never heard of before) server migration will take a number of `find` and `chown` just to be able to start services. There are a number of services that will simply refuse to run with config UID/GID (or permission) mismatches. I do recall a big remapping of system UID/GID that took place sometime post 10.3, but don't recall just when. I'll have to pull drives from the shelf and see how this has worked. I know I spent time remapping them at one point between releases and it wasn't a lot of fun. I just don't see the logic behind randomizing them. Sure if there are adjustments for valid reason to a package or two -- make them, but just to shuffle them between releases -- escapes me.... -- David C. Rankin, J.D.,P.E.
On 2018-06-28 06:01, David C. Rankin wrote:
That does pose a problem for an rsync or cp -a move of configs from 42.3 to 15. Unless there is some SuSEConfig mapping somewhere remapping behind the scenes (which I've never heard of before) server migration will take a number of `find` and `chown` just to be able to start services. There are a number of services that will simply refuse to run with config UID/GID (or permission) mismatches. The `--owner` and `--group` options for rsync both work with name matching by default. So when the UID/GID is different on two machines, but the user/group in question actually does exist, there shouldn't be a problem.
Cheers -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (11)
-
Andrei Borzenkov -
Andrew Colvin -
Anton Aylward -
Carlos E. R. -
Christian Neyers -
David C. Rankin -
David T-G -
Frans de Boer -
John Andersen -
Patrick Shanahan -
Per Jessen