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.
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.
Ack,
Jan
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.
Simo.
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?
Jan
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 ? 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.
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 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.
Simo.
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.
Simo.
Jan
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.
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
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.
On Mon, Sep 26, 2011 at 09:27:38AM -0400, Simo Sorce 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.
Most of the installed base, which everyone who's based the config on our example config, including everyone who runs RPMs, already has an explicit min_id so they won't be affected.
Needs a smarter way to handle this for upgrades.
OK, I'll do what you suggested in a later e-mail.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Jan Zelený -
Simo Sorce -
Stephen Gallagher