Ticket #675 (new enhancement)

Opened 3 years ago

Last modified 2 years ago

Add UID/GID uniqueness plugin for LDB

Reported by: sgallagh Owned by: simo
Priority: minor Milestone: SSSD Deferred
Component: SysDB Version: 1.4.0
Keywords: Cc:
Blocked By: Blocking:
Tests Updated: no Coverity Bug:
Patch Submitted: no Red Hat Bugzilla: 0
Design link:
Feature Milestone:
Design review: Fedora test page:
Chosen: Candidate to push out:
Release Notes:

Description

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.

Change History

comment:1 follow-up: ↓ 2 Changed 3 years ago by 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?

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

comment:2 in reply to: ↑ 1 Changed 3 years ago by sgallagh

Replying to 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.

comment:3 Changed 3 years ago by dpal

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?

comment:4 follow-up: ↓ 5 Changed 3 years ago by 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.

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 3 years ago by dpal

Replying to 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.

comment:6 in reply to: ↑ 5 Changed 3 years ago by sgallagh

Replying to 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

comment:7 follow-up: ↓ 8 Changed 3 years ago by dpal

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

comment:8 in reply to: ↑ 7 Changed 3 years ago by sgallagh

Replying to 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.

comment:9 Changed 3 years ago by dpal

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.

comment:10 Changed 3 years ago by dpal

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.

comment:11 Changed 3 years ago by simo

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).

comment:12 Changed 3 years ago by sgallagh

  • Milestone changed from NEEDS_TRIAGE to SSSD 1.6.0

comment:13 Changed 3 years ago by dpal

  • upgrade set to 0
  • Milestone changed from SSSD 1.6.0 to SSSD 1.7.0

comment:14 Changed 3 years ago by dpal

  • Patch Submitted unset
  • Milestone changed from SSSD 1.8.0 to SSSD 1.9.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.

comment:15 Changed 2 years ago by dpal

"Nice to have" for 1.9.

comment:16 Changed 2 years ago by dpal

  • Milestone changed from SSSD 1.9.0 to SSSD Deferred

comment:17 Changed 2 years ago by dpal

  • Red Hat Bugzilla set to 0
Note: See TracTickets for help on using tickets.