Re: Static UIDs and GIDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 11, 2013 at 08:01:41PM +0000, "Jóhann B. Guðmundsson" wrote:
> On 04/11/2013 07:39 PM, "Jóhann B. Guðmundsson" wrote:
> >On 04/11/2013 07:35 PM, Rex Dieter wrote:
> >>On 04/11/2013 02:30 PM, "Jóhann B. Guðmundsson" wrote:
> >>>What purpose and how useful will /etc/services be with this change?
> >>
> >>I fail to see it's relevance to UIDs/GIDs?  am I missing something?
> >
> >No I am apparently my wits
> >
> >my head was deep into other stuff when I replied
> 
> With my head half way out of my ass the problem we are trying to
> solve is that if I have have multiple servers, UID and GID numbers
> might not be consistent across servers.
> 
> If I have more than one server in my environment, UID and GID numbers
> can quickly become inconsistent between servers and servers running
> other *nix, which means is that the "apache" user might have a UID of
> 80 on Server1, a UID of 82 on Server2, and a UID of 83 on Server3
> which is one of the biggest reasons to standardize consistently UID
> and GID numbers across all servers is so that I can move to a central
> authentication system, such as LDAP. Central authentication systems,
> like LDAP, generally require that LDAP enabled users and groups have
> consistent UIDs and GIDs across all servers that are LDAP connected.
> 
> However even if you are not looking to utilize central authentication
> such as LDAP, you can still run in to problems with having
> inconsistent UID and GID numbers. For example, suppose you have a SAN
> LUN mapped to ServerA. This LUN might have thousands of files stored
> on it. Each file stored on the LUN has the file owner and group
> stored as UID and GID numbers. So if you take this LUN and unmap it
> from ServerA and map it to ServerB, you will have issues if the UID
> and GID numbers are not consistent between ServerA and ServerB. In
> this scenario, you could have a couple of problems. If apache was UID
> 80 on ServerA, and samba is UID 80 on ServerB, after moving the LUN
> samba  owns all of apache files. If there is no UID 80 on ServerB,
> then the file does not have an owner on ServerB, and you simply see
> "404" as the owner when you run a ls –al command and you might also
> have such issues with inconsistent UID/GID numbers across servers
> when you are exporting NFS shares between servers.
> 
> This proposal does not actually solve that does it?
> 
Depends on your definition of solved.  The key to understanding both this
draft and the previous guidelines is that preallocation of uids and gids is
how they intend sysadmins to customize uid and gids on their site.  To use
your example, prior to installing the httpd package, the sysadmin will have
created an apache user and group with the uid and gid they have chosen for
their site.  When the httpd package is installed, it will detect that an
apache user already exists and will use that rather than attempting to
create a new one.  This allows the sysadmin to specify precisely which uid
and gid they need in their environment.  Pure static ids don't allow this so
in that light, this draft would be a step forward.

When the original guideline specifying only dynamic uid and gids was
approved, one of the usages that was specifically cited was that a sysadmin
could customize the setup package to install the users and groups with the
uids and gids they wanted there as the method of preallocation.  I believe
LDAP was mentioned as another method preallocation but we very much wanted
to be sure that the guidelines applied to sites that weren't running LDAP (I
don't recall now if we specifically thought that system ids should not be
stored in LDAP or if that was a later conversation on the topic which was
never brought to bear on the guidelines).

> Hence why should we not simply just have static uid/gid and try to
> unify them between *nix and fix the underlying problem *first*
> instead of adding system users already to the existin problem with
> general users to the mix at packaging level?

As a quick note, one of FPC's first instincts when presented with this draft
was to ask to revise it to have coordinating uid and gid allocation with
other distros.  However, mitr quickly brought up a Debian guideline that
showed that their static system range is nowhere near ours.  So its unlikely
that we'd be able to coordinate this.  Even if we did, it's highly unlikely
that this will fit in with the ranges that are already in existence at sites
throughout the world so creating something that cannot be adapted isn't
going to solve anyone's problems.

Static UIDs are currently not allowed by guidelines.  All uids and gids for new
services are supposed to be dynamically allocated.  As noted in my email,
many services have disregarded that with the result that we've filled up 60
of the 100 new numbers that were made available in F16.  Some of those were
allocated prior to F16 actually allowed it so we probably won't fill up our
allocation in two more releases but we are getting close.

To answer more directly the question of why we should care about this at the
packaging level when the user level problem isn't fully solved: the
packaging level is much more problematic than the user level and solutions
that fit the user level may not be appropriate for packaging.  For instance,
you and Tom Lane both brought up that LDAP seems ill-suited for system
accounts while it is a widely deployed technology for system accounts.
other concerns are that system accounts affect and are affected by
packagers, upstreams, and sysadmins while user accounts are really only
affected by sysadmins.

-Toshio

Attachment: pgpl3RiDiA0sw.pgp
Description: PGP signature

--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux