2014-04-11 8:33 GMT+02:00 Colin Walters <walters@xxxxxxxxxx>:
[2] Overall I'm strongly convinced that the fully-stateless
== fully-atomic-updates model is simply unworkable. We can have
stateless/atomic software installation, but we absolutely do need
to allow for arbitrary operations to be done on system's state between
loading the new version on disk and starting it. Fedora-atomic can have
special support for a few classes of state know in advance, but fully
general software needs fully general post-installation adjustments.
(E.g., where does ALTER TABLE ADD COLUMN on software upgrade fit in the
Fedora-atomic model?)For the fedora-atomic work, the only not-in-Fedora package is shadow-utils because it requires a patch, that still lives in my walters/rpm-ostree COPR.
Patch is linked from my post here:
http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/010099.html
Also, some discussion in the glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=16142
What I'd like to open is a discussion about whether /usr/lib/passwd is the right thing long term. I think it'd be very useful to support it short term, but it's not perfect.
"Clearly not."
There is broad agreement that future access to the user database database (both reading and writing) will be through sssd[1], and that the data model of /etc/{passwd,shadow} is too restrictive—we already want/need to store more data about users than those files allow us to. (E.g. language for physical persons, better namespaces and more accurate password expiration for all accounts.)
So, having /usr/lib/passwd storing the same limited set of data is not the right long-term thing. Unfortunately, AFAIK the fuller interface isn't ready yet.
There is broad agreement that future access to the user database database (both reading and writing) will be through sssd[1], and that the data model of /etc/{passwd,shadow} is too restrictive—we already want/need to store more data about users than those files allow us to. (E.g. language for physical persons, better namespaces and more accurate password expiration for all accounts.)
So, having /usr/lib/passwd storing the same limited set of data is not the right long-term thing. Unfortunately, AFAIK the fuller interface isn't ready yet.
The main case where it breaks is when you have a daemon that runs as non-root and saves state, so you give it its own system user, but not a reserved uid. Daemons in this class will have their uids effectively ordered by package installation order =/
Other posts of the thread have brought up the issue of files owned by the same account.[2]
In the really-long-term, really-hand-wavy, future, I think we need to move away from the 32-bit UIDs[3], and instead use something much longer and well-namespaced (REDHAT_EMPLOYEES/$name, REDHAT_SERVICE_ACCOUNTS/$name, FEDORA_DAEMON_ACCOUNTS/$name, LOCAL_USER/$name, $windows_domain_name/$sid); that would give us a much larger namespace, avoid SID->UID mapping problems, and we could just do the allocation at packaging-time, using FEDORA_DAAEMON_ACCOUNT/$name both in RPM metadata and a password database snippet, without having to worry about overflowing the reserved 1000 UIDs.
AFAIK nobody is working on this, and it would be a huge change, so that's not going to help in the medium term.
Mirek
[1] With really-early-boot-before-sssd processes using ~the existing glibc interfaces and files to avoid a dependency loop.
[1] With really-early-boot-before-sssd processes using ~the existing glibc interfaces and files to avoid a dependency loop.
[3] This could work in the same way SELinux contexts now work in the kernel, having a 32-bit UID as an internal identifier that changes between reboots, and longer usernames as the long-term storage mechanism. New syscalls would work directly with usernames; older applications would still work with the UIDs and the APIs would work as long as they don't try to store the UID values anywhere.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
