Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 452342

Summary: Fedora Directory Server does not like read only root filesystem
Product: [Retired] 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 17:09:54 UTC 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-21 01:54:48 UTC
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-21 02:09:55 UTC
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 14:35:27 UTC
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 23:34:30 UTC
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 14:36:02 UTC
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 17:53:12 UTC
(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 16:06:30 UTC
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-03 01:51:04 UTC
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-03 02:08:33 UTC
(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 11:14:45 UTC
[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 11:46:29 UTC
Ok, I fixed my problem using single user mode..
But testing is pending for the bug.

Comment 11 Rich Megginson 2011-07-19 14:05:49 UTC
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 06:17:26 UTC
Based on comment#11 marking the bug as VERIFIED.