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 > more dangerous. Yeah, breaking systems on upgrade is a big NO NO. > > 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. 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 > security issues. 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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
