> 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.
I think we misunderstood each other here. Of course I didn't mean any automatic action to be taken. Rather I would warn admin that he should move the ID range by hand. I was for example thinking about warnings when using sss_* tools. > So we *must* handle properly the case where we have pre-existing users > in the 1000 range. Agreed. > 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. Ok, in that case I see no problem with the approach you suggested. Jan
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
