2014-04-11 8:33 GMT+02:00 Colin Walters <walt...@verbum.org>:
> 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.
> 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.
[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?)
[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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
