2009/4/28 Ondřej Vašík <ovasik@xxxxxxxxxx>: > > Any other idea or some prefered solution? Another idea (not exclusive with the uuid approach) is to have a global system flag somewhere in /etc which lets admins make the tradeoff between: * Compatibility with previous releases, large uid space for their own use, many system daemons will get dynamic uids installed * Large system uid space, incompatible assignment with earlier releases Basically if you pick the first option, then when some new daemon not in the static list is installed it gets "adduser" dynamically (and the files have to be chowned, needs RPM level work most likely to not break -V etc.). This approach requires a "flag day" where we bump the system uid space of course. Oh regardless of anything else, one thing SSSD or whatever really should add is something to distinguish between a uid for some system service and a uid intended for an actual human (the heuristic of having a $HOME be in /home is kinda ugly). -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
