* 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!

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

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 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 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.

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

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

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. 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 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