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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel