Bug 447758 - smbldap-useradd does not properly set permissions on user home when using LDAP slaves
smbldap-useradd does not properly set permissions on user home when using LDA...
Product: Fedora
Classification: Fedora
Component: smbldap-tools (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Paul Howarth
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-21 12:40 EDT by John Holmstadt
Modified: 2018-04-11 04:11 EDT (History)
1 user (show)

See Also:
Fixed In Version: 0.9.5-2.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-30 18:23:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch for smbldap-useradd on smbldap-tools-0.9.4-1.fc8 (760 bytes, patch)
2008-05-21 12:44 EDT, John Holmstadt
no flags Details | Diff
Alternative patch that avoids the wait (571 bytes, patch)
2008-05-23 07:42 EDT, Paul Howarth
no flags Details | Diff

  None (edit)
Description John Holmstadt 2008-05-21 12:40:29 EDT
Description of problem:
When creating an account on an machine that is an LDAP slave, smbldap-adduser
tries to set the user's home directory permissions before the account info has
replicated back from the master LDAP server to the slave. This results in a
silent failure to set the user's directory permissions (because stderr has been
redirected to /dev/null). User's directory permissions must be set manually
afterwards to ensure proper operation.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run: smbldap-adduser -a -m -N Joe -S User -P joeuser
2. ls -la /home/joeuser
Actual results:
User's home directory permissions not set

Expected results:
User's home directory permissions set correctly

Additional info:
Using openldap-2.3.39-3.fc8 on slave, openldap-2.2.29-1.FC4 on master.
Comment 1 John Holmstadt 2008-05-21 12:44:28 EDT
Created attachment 306276 [details]
Patch for smbldap-useradd on smbldap-tools-0.9.4-1.fc8

Patch to make smbldap-useradd wait until "id username" responds with something
other than "No such user". No idea if "id" is the tool best suited for this
task, but it Works For Me(tm).
Comment 2 Paul Howarth 2008-05-23 07:42:32 EDT
Created attachment 306484 [details]
Alternative patch that avoids the wait

Here's my alternative suggestion. Instead of waiting for the username to become
visible in LDAP, set the ownership of the home directory by UID instead of
name. This way, chown doesn't need to do the name-to-UID mapping and so there's
no need to check for LDAP replication having happened.
Comment 3 Matěj Cepl 2008-06-28 00:39:31 EDT
Just note from your friendly bug triager -- I think, that the correct status of
this bug according to
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow is ASSIGNED. Please,
correct this bug to the right state, if I am wrong.
Comment 4 Paul Howarth 2008-06-28 05:00:30 EDT
smbldap-tools-0.9.5-2 packages including my alternative patch (and also proposed
fixes for Bug #441833 and Bug #430105) can be found here:


I'd appreciate some feedback before I issue these as official Fedora updates.
Comment 5 John Holmstadt 2008-07-07 14:57:45 EDT

Sorry for the late response. Your alternative patch worked well for me.

Comment 6 Fedora Update System 2008-07-08 07:20:20 EDT
smbldap-tools-0.9.5-2.fc8 has been submitted as an update for Fedora 8
Comment 7 Fedora Update System 2008-07-08 22:47:59 EDT
smbldap-tools-0.9.5-2.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update smbldap-tools'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-6199
Comment 8 Paul Howarth 2008-07-30 18:23:21 EDT
This update is now in the main Fedora 8 updates repository.

Note You need to log in before you can comment on or make changes to this bug.