[SSSD] [PATCH] Increase the local domain min_id/max_id

Jan Zelený jzeleny at redhat.com
Mon Sep 26 14:47:58 UTC 2011


> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110926/d488b215/attachment.sig>


More information about the sssd-devel mailing list