#95 magicPrivateGroups set to FALSE, Local user added with gidNumber of 0
Closed: Fixed None Opened 14 years ago by jgalipea.

Description:

With magicPrivateGroups set to FALSE or not defined in sssd.conf (default of FALSE), adding a user is successful, but sets the user's gidNumber to 0.

dn: name=user1000,cn=users,cn=LOCAL,cn=sysdb
objectClass: user
name: user1000
uidNumber: 1000
gidNumber: 0
fullName: user1000
gecos: user1000
homeDirectory: /home/user1000
loginShell: /bin/bash
createTimestamp: 1249910287
distinguishedName: name=user1000,cn=users,cn=LOCAL,cn=sysdb

Subsequently searching for the user, the user is not found. Debug output shows the following message:

  [sssd[nss]] [fill_pwent] (1): Incomplete user object for user1000[1000]! Skipping

Deleting the user is completes successfully. but the following debug message is logged:

   [sssd[nss]] [nss_cmd_getpwnam] (2): No matching domain found for [user1000], fail!

Expected Results:

  1. If gidNumber is required when magicPrivateGroups is set to FALSE, then attempting to add a user without defining gidNumber should result in a failure with appropriate error message.

  2. Successful deletion of a user with gidNumber of 0 - should not log a fail message.

Configuration Tested:

[services]
description =  Local Service Configuration
activeServices = nss, pam
reconnection_retries = 3

[services/nss]
description = NSS Responder Configuration
filterGroups = root
filterUsers = root
debug-level = 4

[services/dp]
description = Data Provider Configuration
debug-level = 4

[services/pam]
description = PAM Responder Configuration

[services/monitor]
description = Service Monitor Configuration

[domains]
description = Domains served by SSSD
domains = LOCAL

[domains/LOCAL]
description = LOCAL Users domain
enumerate = 3
minId = 1000
maxId = 1010
legacy = TRUE
useFullyQualifiedNames = TRUE
provider = local

SSSD version:

sssd-2009081001-0.fc11.i586


Fields changed

description: Description:

With magicPrivateGroups set to FALSE or not defined in sssd.conf (default of FALSE), adding a user is successful, but sets the user's gidNumber to 0.

dn: name=user1000,cn=users,cn=LOCAL,cn=sysdb
objectClass: user
name: user1000
uidNumber: 1000
gidNumber: 0
fullName: user1000
gecos: user1000
homeDirectory: /home/user1000
loginShell: /bin/bash
createTimestamp: 1249910287
distinguishedName: name=user1000,cn=users,cn=LOCAL,cn=sysdb

Subsequently searching for the user, the user is not found. Debug output shows the following message:

[sssd[nss]] [fill_pwent] (1): Incomplete user object for user1000[1000]! Skipping

Deleting the user is completes successfully. but the following debug message is logged:

[sssd[nss]] [nss_cmd_getpwnam] (2): No matching domain found for [user1000], fail!

Expected Results:

  1. If gidNumber is required when magicPrivateGroups is set to FALSE, then attempting to add a user without defining gidNumber should result in a failure with appropriate error message.

  2. Successful deletion of a user with gidNumber of 0 - should not log a fail message.

Configuration Tested:

[services]
description = Local Service Configuration
activeServices = nss, pam
reconnection_retries = 3

[services/nss]
description = NSS Responder Configuration
filterGroups = root
filterUsers = root
debug-level = 4

[services/dp]
description = Data Provider Configuration
debug-level = 4

[services/pam]
description = PAM Responder Configuration

[services/monitor]
description = Service Monitor Configuration

[domains]
description = Domains served by SSSD
domains = LOCAL

[domains/LOCAL]
description = LOCAL Users domain
enumerate = 3
minId = 1000
maxId = 1010
legacy = TRUE
useFullyQualifiedNames = TRUE
provider = local

SSSD version:

sssd-2009081001-0.fc11.i586
=> Description:

With magicPrivateGroups set to FALSE or not defined in sssd.conf (default of FALSE), adding a user is successful, but sets the user's gidNumber to 0.
{{{
dn: name=user1000,cn=users,cn=LOCAL,cn=sysdb
objectClass: user
name: user1000
uidNumber: 1000
gidNumber: 0
fullName: user1000
gecos: user1000
homeDirectory: /home/user1000
loginShell: /bin/bash
createTimestamp: 1249910287
distinguishedName: name=user1000,cn=users,cn=LOCAL,cn=sysdb
}}}
Subsequently searching for the user, the user is not found. Debug output shows the following message:
{{{
[sssd[nss]] [fill_pwent] (1): Incomplete user object for user1000[1000]! Skipping
}}}
Deleting the user is completes successfully. but the following debug message is logged:
{{{
[sssd[nss]] [nss_cmd_getpwnam] (2): No matching domain found for [user1000], fail!
}}}

Expected Results:

  1. If gidNumber is required when magicPrivateGroups is set to FALSE, then attempting to add a user without defining gidNumber should result in a failure with appropriate error message.

  2. Successful deletion of a user with gidNumber of 0 - should not log a fail message.

Configuration Tested:
{{{
[services]
description = Local Service Configuration
activeServices = nss, pam
reconnection_retries = 3

[services/nss]
description = NSS Responder Configuration
filterGroups = root
filterUsers = root
debug-level = 4

[services/dp]
description = Data Provider Configuration
debug-level = 4

[services/pam]
description = PAM Responder Configuration

[services/monitor]
description = Service Monitor Configuration

[domains]
description = Domains served by SSSD
domains = LOCAL

[domains/LOCAL]
description = LOCAL Users domain
enumerate = 3
minId = 1000
maxId = 1010
legacy = TRUE
useFullyQualifiedNames = TRUE
provider = local
}}}
SSSD version:

sssd-2009081001-0.fc11.i586

milestone: SSSD 1.0 => Iteration 6
owner: somebody => jhrozek

Fields changed

component: SSSD => sss_tools

Fields changed

priority: minor => critical

This is a serious issue that should be addressed in time for 0.5.0.

priority: critical => blocker

Setting correct component as the problem is in sysdb, not tools.

component: sss_tools => SSSD
status: new => assigned

After some discussion on IRC, we've decided to simply enforce that MagicPrivateGroups=TRUE for the native local provider, eliminating the need for this setting in the config file.

owner: jhrozek => sgallagh
status: assigned => new

Fields changed

status: new => assigned

Fixed in 2ec5bcb

From now on, the local provider will always function as if magicPrivateGroups is set to TRUE.

fixedin: => 0.5.0
resolution: => fixed
status: assigned => closed

Fields changed

rhbz: => 0

Metadata Update from @jgalipea:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD 0.5.0

7 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/1137

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