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.
> 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
more dangerous.
> Another option would be to set the default to a higher number (not sure
> 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. 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
security issues.
> I know it is a bit more owrk, but I don;t think we want to break stuff
> for users that have it working just fine.
Under no circumstances should we ever CHANGE a user's ID on upgrade.
However, if the system is using the defaults (no explicit min_id set),
then I think we DO need to do a search against the local provider sysdb
at startup and set the internal min_id to whatever is actually in use.