On Mon, 2011-09-26 at 16:16 +0200, Jan Zelený wrote:
> On Mon, 2011-09-26 at 15:37 +0200, Jan Zelený wrote:
> > > On Mon, 2011-09-26 at 10:57 +0200, Jakub Hrozek wrote:
> > > > https://fedorahosted.org/sssd/ticket/1007
> > > >
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=741164
> > > >
> > > > shadow-utils recently changed their min_id value from 500 to 1000.
> > > > Our local provider min_id used to be 1000 which would collide with
> > > > their UIDs.
> > > >
> > > > This patch bumps up the min_id and max_id values.
> > >
> > > NACK.
> > > This will break the local domain on upgrades.
> > >
> > > Needs a smarter way to handle this for upgrades.
> > How about RPM scriptlet handling this and a notice in release notes?
> > Wouldn't that be sufficient?
> What would you do in the rpm update ?
That's a bit tricky. UIDs and GIDs might be already affecting other parts of
the system (ownership of various files for instance) and it is difficult to
handle every possible thing that needs to be changed automatically.
You are *not* thinking of changing all file systems permissions and ACLs
automatically, right ? That's impossible, see below.
> Also how do you handle this on other platforms ?
> Should we rely on packagers to notice and "fix" this ?
> Seems dangerous to rely on that.
I was thinking more about sysadmins than packagers but I suppose that's even
Yeah, breaking systems on upgrade is a big NO NO.
> Another option would be to set the default to a higher number
> if 5000 is right or not) and then do a quick search in the local domain.
> if the local domain has entries in the range 1000 we automatically tune
> down the default unless it has been explicitly set in the config file.
I don't think this is the right approach. Maybe if combined with a strong
warning somewhere (/var/log/messages ?). IMO admins should be warned that IDs
need to be bumped.
You cannot "bump" existing IDs, no more than you can automatically
change uids in ACLs all over the local and possibly NFS or other
remote/removable mounted file systems.
So we *must* handle properly the case where we have pre-existing users
in the 1000 range.
The min_uid feature is useful as a default to avoid clashes by default
but it is not really a security feature, so I don;t think demanding
changes here makes a lot of sense.
In case they don't and any system daemon in the future gets
UID that overlaps with UID in the local database, it might cause some serious
That's always the case and out of our control.
HOwever no it is unlikely to have local user overlap in a normal system
because adduser always does a getpwuid to check it is not creating a
duplicated uid IIRC.
Simo Sorce * Red Hat, Inc * New York