#675 Add UID/GID uniqueness plugin for LDB
Closed: wontfix 3 years ago by pbrezina. Opened 13 years ago by sgallagh.

We need to ensure that there is no overlap between identifiers for a user or group. We should never store a user or group whose ID matches another entry in the sysdb.

This is probably best handled with an LDB plugin for the sysdb.


And what would you do if you get into this situation? In the long run there probably should be a way to resolve the conflict based on the configuration. If the UID/GID comes from a secondary domain that collides with the primary domain who should win? Would you overwrite?

IMO first step is just to prevent overwriting and have a good feedback about the failed operation. Concern: if it is implemented as a plugin we need to make sure that the caller of the LDB interface gets the right error and acts accordingly otherwise it can panic and assume that LDB is not writable and start throwing all sorts of cryptic errors.

The second step - long term allow the defining the rules of the conflict resolution in the sssd.conf

Replying to [comment:1 dpal]:

And what would you do if you get into this situation? In the long run there probably should be a way to resolve the conflict based on the configuration. If the UID/GID comes from a secondary domain that collides with the primary domain who should win? Would you overwrite?

This is only applicable to conflicts within the same domain. Separate domains have separate caches.

IMO first step is just to prevent overwriting and have a good feedback about the failed operation. Concern: if it is implemented as a plugin we need to make sure that the caller of the LDB interface gets the right error and acts accordingly otherwise it can panic and assume that LDB is not writable and start throwing all sorts of cryptic errors.

The purpose of the plugin is exactly this: to prevent writing a second user with an ID that is already in use.

The second step - long term allow the defining the rules of the conflict resolution in the sssd.conf

There is no conflict resolution. First one cached is the only one ever seen. Proper resolution requires fixing the broken server. This is just to ensure that our behavior on the client is always consistent.

I am talking about the broader case here. If there are duplicate UIDs or GIDs on the server it is a server problem and should be fixed there. SSSD should be vocal and complain if it detects. This is fine. No argument here.

But I see the issue if users A & B from two different domains have the same UID or GID. Will this cause some confusion for the file system? And potential security risks with wrong user getting file access?

Different domains must user different ranges.
The only other options is to remap IDs.
In any case nothing that concern the work this plugin is going to do as the remapping (if we ever want to go that route in SSSD as opposed to handle it in the server through a compat tree or similar) would happen before the uniqueness plugin is involved.

Replying to [comment:4 simo]:

Different domains must user different ranges.
The only other options is to remap IDs.
In any case nothing that concern the work this plugin is going to do as the remapping (if we ever want to go that route in SSSD as opposed to handle it in the server through a compat tree or similar) would happen before the uniqueness plugin is involved.

I completely agree that they should, as well as one domain should also have unique UIDs and GIDs. But this is not the case (this this bug) and I do not see a reason to handle one case (dups inside one domain) and not handle another (dups in different domains). In both cases it is a server misconfiguration but detecting and reporting it and having a way to mitigate it IMO is the right approach. The priority is low though.

Replying to [comment:5 dpal]:

I completely agree that they should, as well as one domain should also have unique UIDs and GIDs. But this is not the case (this this bug) and I do not see a reason to handle one case (dups inside one domain) and not handle another (dups in different domains). In both cases it is a server misconfiguration but detecting and reporting it and having a way to mitigate it IMO is the right approach. The priority is low though.

This can't be done, Dmitri. The domains are logically separate for a reason. They have no insight into the contents of any other domain.

If there are overlapping IDs between separate domains, they cannot conflict because only the first domain to match will reply (as specified by the order in the {{{domains = }}}line in the sssd.conf

When getpwid is called does SSSD consult just primary domain or all domains?

Replying to [comment:7 dpal]:

When getpwid is called does SSSD consult just primary domain or all domains?

All domains are tried in series, stopping at the first domain that can answer it.

So what I am suggesting is to add an option to continue across all domains and if spotted a duplicate have a way to determine which one should be used or if an error should be returned.

I see it as a term mode to help the admins to resolve conflicts between domains. Not a high priority - just an idea for future.

Please lets all stop hijacking this ticket. Lets move design discussions to the sssd-devel mailing list.

(However, this behaviour was a design decision, please provide compelling evidence of why it would make sense to change it on the sssd-devel list if you want to discussed further).

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.6.0

Fields changed

coverity: =>
milestone: SSSD 1.6.0 => SSSD 1.7.0
upgrade: => 0

If we want to replace the OS utils we want to have our utilities fixed at least to do the right thing for the local domain.

milestone: SSSD 1.8.0 => SSSD 1.9.0
patch: => 0

"Nice to have" for 1.9.

blockedby: =>
blocking: =>
rhbz: =>

Fields changed

feature_milestone: =>
milestone: SSSD 1.9.0 => SSSD Deferred

Fields changed

rhbz: => 0

Metadata Update from @sgallagh:
- Issue assigned to simo
- Issue set to the milestone: SSSD Patches welcome

7 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

3 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1717

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata