#2800 Relax POSIX check
Closed: Fixed None Opened 3 years ago by jhrozek.

From the downstream bugzilla:
Sumit Bose 2015-09-21 04:13:57 EDT

I think checking against the LDAP port make sense as well, the user might have configured to use POSIX attributes in SSSD although there are none defined in AD.

I did some checks with the AD GUI and it looks like -2 cannot be entered. But there are some migration utilities which read NIS databases and put the data in the AD LDAP tree, maybe here there sre not such strict checks. Iirc -1 was often used as the UID of 'nobody' and -2 as the GID of 'nogroup'. They were transparently translated to the maximal and second maximal ID value on the system.

Maybe we can relax the check a bit and be happy if we find a UID or GID attribute at all? To make this more reliable we might want to improve the filter which is currently only '(|(uidNumber=)(gidNumber=))' by adding the objectclasses for user and group objects as well?


Fields changed

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
mark: no => 0
owner: somebody => preichl
review: True => 0
selected: =>
testsupdated: => 0

Fields changed

patch: 0 => 1

This is hitting customers upgrading from 1.10 or earlier to 1.11 in case their POSIX attributes are funky. Should be a blocker for 1.13.2.

We already have positive feedback about Pavel's patch.

priority: major => critical

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13.2

resolution: => fixed
status: new => closed

Metadata Update from @jhrozek:
- Issue assigned to preichl
- Issue set to the milestone: SSSD 1.13.2

2 years ago

Login to comment on this ticket.

Metadata