Hide Forgot
Description of problem: If enable auto-creation of homes, via e. g. # authconfig --enablesssd --enablesssdauth --enablemkhomedir --update then new homes have permission 755, what can cause a security leak. Version-Release number of selected component (if applicable): oddjob-mkhomedir-0.31.5-3.el7.x86_64 How reproducible: Always. Steps to Reproduce: - Setup auto home creation (e. g. for users authenticated against AD) - Login - home is created with permission 755 Actual results: home is created with permission 755 Expected results: home should be created with permission 700 or max. 750 Additional info: Same bug exists in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=995097 But it's not fixed there and I opened a new one, to show, that this issue also exists in RHEL7.
As in bug #995097, does removing the part of /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf that passes a umask (via a -u parameter) to the helper resolve this? Because we can absolutely do that.
Created attachment 934297 [details] Error message during login (In reply to Nalin Dahyabhai from comment #2) > As in bug #995097, does removing the part of > /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf that passes a umask (via a -u > parameter) to the helper resolve this? Because we can absolutely do that. No. If I delete this file, there's shown an error for a second after I entered the password. And after the authentication, there's a second error and then I got logged out again (and the home wasn't created).
Created attachment 934298 [details] Error after login
Created attachment 934299 [details] messages and secure log from the login try
(In reply to Marc Muehlfeld from comment #3) > Created attachment 934297 [details] > Error message during login > > (In reply to Nalin Dahyabhai from comment #2) > > As in bug #995097, does removing the part of > > /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf that passes a umask (via a -u > > parameter) to the helper resolve this? Because we can absolutely do that. > > No. > > If I delete this file, there's shown an error for a second after I entered > the password. And after the authentication, there's a second error and then > I got logged out again (and the home wasn't created). I'm sorry I wasn't clearer - I meant removing the -u flag from the configuration for the helper, not the entire file. The file's contents should change from: ============================================================================== <?xml version="1.0"?> <!-- This configuration file snippet controls the oddjob daemon. It provides access to mkhomedir functionality via a service named "com.redhat.oddjob_mkhomedir", which exposes a single object ("/"). The object allows the root user to call any of the standard D-Bus introspection interface's methods (these are implemented by oddjobd itself), and also defines an interface named "com.redhat.oddjob_mkhomedir", which provides two methods. --> <oddjobconfig> <service name="com.redhat.oddjob_mkhomedir"> <object name="/"> <interface name="org.freedesktop.DBus.Introspectable"> <allow min_uid="0" max_uid="0"/> <!-- <method name="Introspect"/> --> </interface> <interface name="com.redhat.oddjob_mkhomedir"> <method name="mkmyhomedir"> <helper exec="/usr/libexec/oddjob/mkhomedir -u 0002" arguments="0" prepend_user_name="yes"/> <!-- no acl entries -> not allowed for anyone --> </method> <method name="mkhomedirfor"> <helper exec="/usr/libexec/oddjob/mkhomedir -u 0002" arguments="1"/> <allow user="root"/> </method> </interface> </object> </service> </oddjobconfig> ============================================================================== to: ============================================================================== <?xml version="1.0"?> <!-- This configuration file snippet controls the oddjob daemon. It provides access to mkhomedir functionality via a service named "com.redhat.oddjob_mkhomedir", which exposes a single object ("/"). The object allows the root user to call any of the standard D-Bus introspection interface's methods (these are implemented by oddjobd itself), and also defines an interface named "com.redhat.oddjob_mkhomedir", which provides two methods. --> <oddjobconfig> <service name="com.redhat.oddjob_mkhomedir"> <object name="/"> <interface name="org.freedesktop.DBus.Introspectable"> <allow min_uid="0" max_uid="0"/> <!-- <method name="Introspect"/> --> </interface> <interface name="com.redhat.oddjob_mkhomedir"> <method name="mkmyhomedir"> <helper exec="/usr/libexec/oddjob/mkhomedir" arguments="0" prepend_user_name="yes"/> <!-- no acl entries -> not allowed for anyone --> </method> <method name="mkhomedirfor"> <helper exec="/usr/libexec/oddjob/mkhomedir" arguments="1"/> <allow user="root"/> </method> </interface> </object> </service> </oddjobconfig> ============================================================================== After the change, the <helper> node should no longer be configured to pass a umask value to the helper, allowing it to read the configured value from /etc/login.defs, which by default matches the value you prefer.
(In reply to Nalin Dahyabhai from comment #6) > I'm sorry I wasn't clearer - I meant removing the -u flag from the > configuration for the helper, not the entire file. Ups. Sorry. :-) If I remove the '-u 0002', then the created home directory gets permission 700. So this would help.
Great! We'll do that, then.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0446.html