Bug 452342

Summary: Fedora Directory Server does not like read only root filesystem
Product: [Community] 389 Reporter: W. Michael Petullo <redhat>
Component: Directory ServerAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: low Docs Contact:
Priority: low    
Version: 1.1.1CC: amsharma, mike
Target Milestone: ---Keywords: VerifiedUpstream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 12:09:54 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description W. Michael Petullo 2008-06-20 21:54:48 EDT
Description of problem:
I have installed FDS on Fedora 9 and configured it using ipa-server-install. When I configured my 
system to boot with a read only root filesystem, FDS would no longer start. The server stated that 
/etc/dirsrv/slapd-XXX-XXX/dse.ldif was not writable. 

Version-Release number of selected component (if applicable):
fedora-ds-base-1.1.1-1.fc9.i386

How reproducible:
Every time

Steps to Reproduce:
1. Install and configure FDS.
2. Set READONLY=yes in /etc/sysconfig/readonly-root
3. Reboot
  
Actual results:
FDS will not start:

[20/Jun/2008:21:41:10 -0400] dse - The DSE database stored in "/etc/dirsrv/slapd-XXX-XXX/dse.ldif" 
is not writeable
[20/Jun/2008:21:41:10 -0400] dse - Unable to write "/etc/dirsrv/slapd-XXX-XXX/dse.ldif": Netscape 
Portable Runtime error -5948 (Cannot write to a read-only file system.)
[20/Jun/2008:21:41:10 -0400] - SSL alert: Security Initialization: NSS initialization failed (Netscape 
Portable Runtime error -8174 - security library: bad database.): certdir: /etc/dirsrv/slapd-XXX-XXX
[20/Jun/2008:21:41:10 -0400] - ERROR: NSS Initialization Failed.

Expected results:
FDS should run when /etc and / are read only. Shouldn't /var be used if a file needs write capability?

Additional info:
I have mounted /var and /tmp read/write.
Comment 1 W. Michael Petullo 2008-06-20 22:09:55 EDT
For a temporary workaround, I have moved /etc/dirsrv/slapd-XXX-XXX/ to /var/lib/dirsrv/etc-slapd-
XXX-XXX. I then made a symbolic link back to /etc/dirsrv/slapd-XXX-XXX. This allows FDS to start.
Comment 2 Rich Megginson 2008-06-23 10:35:27 EDT
The symlink workaround is your best bet.

Fedora DS allows you to update the config dynamically, over LDAP.  So when you
change cn=config, those changes are immediately flushed out to dse.ldif.  And
it's not just user-initiated changes, especially if you are running replication,
because we save state information here too.

When we moved from the old style of a single prefix to the FHS layout, there was
a big debate about this issue - config files should go in /etc, writable files
in /var/lib.  But what about writable config files?  There was no clear answer
at the time, so we decided to go with /etc, and group all of the config files
together, read-only (e.g. key/cert db files) with the writable ones for
simplicity.  We figured savvy admins would use a symlink if they wanted to mount
/etc read-only.

If you build from source, you can specify a different directory to be used for
instance configuration files - see configure --help for details.
Comment 3 W. Michael Petullo 2008-10-19 19:34:30 EDT
One problem with the symlink solution is that it has the potential to break SELinux. If I run restorecon, then the context of the files in directory pointed to by /etc/dirsrv/slapd-XXX-XXX will be given the context associated with /var/..., not /etc/... . This could cause problems down the road if the SELinux policy becomes more restrictive. Stuff in /etc/dirsrv/slapd-XXX-XXX will not be labeled as the SELinux policy developer intends.

The FHS 2.3 says (emphasis mine):

The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; *** it must be static *** and cannot be an executable binary.

Later, it admits:

mtab does not fit the static nature of /etc: it is excepted for historical reasons.
Comment 4 Rich Megginson 2008-10-20 10:36:02 EDT
Yes, this will cause problems for selinux.  But note that there are many tools such as puppet and cobbler that attempt to modify files in /etc at run time, in order to push out configuration changes to manage multiple systems.  There are also other files in /etc/sysconfig/* that are meant to be modified.  How do admins reconcile this with the need to mount /etc read-only?

OTOH, I've heard that debian and possibly other distros enforce a strict read-only file system mount of /etc.  I guess you have to get your configuration correct, then change the mount to read-only.  I can certainly see where this helps with security.
Comment 5 W. Michael Petullo 2008-11-29 12:53:12 EST
(In reply to comment #4)
> OTOH, I've heard that debian and possibly other distros enforce a strict
> read-only file system mount of /etc.  I guess you have to get your
> configuration correct, then change the mount to read-only.  I can certainly see
> where this helps with security.

Yes. That is my intent. In my mind, /etc should support an optional read-only mount. I suspect this is why the FHS folks define /etc as they do. It's also more than security. It's sometimes necessary for someone to validate a configuration and then deploy it in such a way that possibly well-meaning subordinates won't accidentally sudo a change. Or, at least, a read-only mount reinforces this policy even if it can be circumvented with some work.
Comment 6 Rich Megginson 2008-12-01 11:06:30 EST
The way Fedora DS works, dse.ldif must be writable.  dse.ldif cannot live on a read-only file system.

The alternative is that fedora ds can be built with a different instance configuration directory at configure time:
  --with-instconfigdir=/path
                          Base directory for instance specific writable
                          configuration directories (default
                          $sysconfdir/$PACKAGE_NAME)

The default is /etc/dirsrv (that's what $sysconfdir/$PACKAGE_NAME expands to if doing an rpmbuild).  So you could build fedora ds and specify /var/lib/dirsrv or something like that.  Then you would have /var/lib/dirsrv/slapd-instance/dse.ldif, schema/, cert8.db, etc. etc.
Comment 7 W. Michael Petullo 2010-03-02 20:51:04 EST
Why can't dse.ldif be placed in /var/lib... by default? This seems to be what the FHS whould expect. Other files, such as schemas, that don't typically change once a system goes live could remain in /etc.
Comment 8 Rich Megginson 2010-03-02 21:08:33 EST
(In reply to comment #7)
> Why can't dse.ldif be placed in /var/lib... by default? This seems to be what
> the FHS whould expect. Other files, such as schemas, that don't typically
> change once a system goes live could remain in /etc.    

by using configure with the --instconfigdir=path argument, you can place dse.ldif wherever you want.  As far as why /etc was chosen as the default location - we debated this long and hard, and the FHS was just not crystal clear about this.  We finally decided that, since dse.ldif is a config file, most people would expect it to be somewhere under /etc.
Comment 9 Amita Sharma 2011-07-19 07:14:45 EDT
[root@testvm ~]# vim /etc/sysconfig/readonly-root
[root@testvm ~]# reboot

Broadcast message from root@testvm.pnq.redhat.com
	(/dev/pts/0) at 16:25 ...

The system is going down for reboot NOW!
[root@testvm ~]# Connection to 10.65.201.178 closed by remote host.
Connection to 10.65.201.178 closed.

[root@testvm ~]# service dirsrv start
Starting dirsrv: 
    testvm1...[19/Jul/2011:16:27:51 +051800] dse - The DSE database stored in "/etc/dirsrv/slapd-testvm1/dse.ldif" is not writeable
[19/Jul/2011:16:27:51 +051800] dse - Unable to write "/etc/dirsrv/slapd-testvm1/dse.ldif": Netscape Portable Runtime error -5948 (Cannot write to a read-only file system.)
[19/Jul/2011:16:27:51 +051800] - SSL alert: Security Initialization: NSS initialization failed (Netscape Portable Runtime error -8187 - security library: invalid arguments.): certdir: /etc/dirsrv/slapd-testvm1
[19/Jul/2011:16:27:51 +051800] - ERROR: NSS Initialization Failed.
                                                           [FAILED]
  *** Warning: 1 instance(s) failed to start

:( If it was not fixed? then what I need to test?
I saw no patch here after when I executed above commands...
now I want my root as normal?? How should I do that :(
Comment 10 Amita Sharma 2011-07-19 07:46:29 EDT
Ok, I fixed my problem using single user mode..
But testing is pending for the bug.
Comment 11 Rich Megginson 2011-07-19 10:05:49 EDT
Fixed/verified upstream.  The directory server can be built with an alternate location for distros other than RHEL or Fedora.
Comment 12 Amita Sharma 2011-07-20 02:17:26 EDT
Based on comment#11 marking the bug as VERIFIED.