On Fri, Sep 5, 2008 at 11:31 PM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 05, 2008 at 07:40:13PM -0700, Joshua Piccari wrote:
> > Hi all,
> > I am setting up a few jails and I want them all to use the same /etc
> files
> > (with the exception of the files related to the password files and
> > databases), so I mounted a shared /etc folder as a nullfs with read-only
> > permissions. The problem is that using utilities like pw or chpass create
> > temporary files in /etc and that file system is mounted read-only.
> > So is there a way to force any utilities that create temp files in /etc
> to
> > use another location, something like /usr/local/etc for example?
>
> I've had a chat with another user off-list about this, and the
> conclusion reached is that your mounting of /etc read-only is a bad
> idea, for many different reasons. Let's step through things slowly, so
> that hopefully it'll make sense.
>
> Foremost, /etc is mounted read-only, so what purpose does it serve to be
> using passwd or group-editing utilities on that system? You'd need r/w
> access to be able to accomplish that.
>
> Secondly, utilities like vipw(8), chpass(1), pw(8), and many others all
> create temporary files in /etc for security reasons: the temporary files
> *must* be on the same filesystem. In your case, /etc is its own
> filesystem, mounted read-only. So, placing the temporary files (e.g.
> /etc/pw.XX when using vipw(8)) on a separate filesystem or separate
> location is not plausible. Regarding the security implications, others
> will have to chime in here.
>
> Thirdly, some (but not all) of the utilities support command-line flags
> that allow an alternative directory to /etc:
>
> pw(8) -V flag
> vipw(8) -d flag
> pwd_mkdb(8) -d flag
> chpass(1) no support
> passwd(1) no support
> rmuser(8) no support
> adduser(8) no support
>
> Fourthly, there are periodic(8) scripts which explicitly refer to
> /etc/master.passwd and do not support an alternative directory. Those
> scripts will break, and disabling them is not recommended.
>
> Finally, some other caveats/situations which will likely arise:
>
> - The administrator (you) will have to remember to use the above flags
> every time they use said utilities; chances are you'll forget,
> especially since the flags aren't all the same,
> - A user of your jail may become very surprised when they find
> passwd, group, or other files missing from /etc,
> - Third-party software which reads /etc/passwd or related files will
> fail since you'd be using an alternative /etc directory. I'm
> pretty sure we have some ports which use rmuser/adduser (meaning
> the software itself, not necessarily the port installation part).
>
> Hope this sheds some light on things.
>
> --
> | Jeremy Chadwickjdc at parodius.com |
> | Parodius Networking http://www.parodius.com/ |
> | UNIX Systems Administrator Mountain View, CA, USA |
> | Making life hard for others since 1977. PGP: 4BD6C0CB |
>
>
Thanks so much Jeremy.
You sure did give out lots of information. Unfortunately none that I can
really use. Let me explain my situation a bit more.
I have a shared /etc folder that is mounted read-only to the different jails
that share it. Some of the configuration files which need to be dynamic from
jail to jail are replaced with symbolic links to the jails /usr/local/etc
folder. The reason for mount /etc as read-only is to ensure that none of the
jails accidentally modify the configurations for all the jails sharing these
configurations. However, there is an issue with creating temp files on a
read-only system which means I will have to work around this somehow. I
thought about setting the schg flag on all the files in the shared /etc
folder but I don't want one jail to be able to add a rc.d script for every
jail.
Anyways, hope that helps clarify things. Also, is there a way to just move
the password files/databases to /usr/local/etc instead, I vaguely remember
something in one of the man pages about alternate passwd/master.passwd
locations, probably the flags you noted above. I'll check that out more
tomorrow after some good sleep.
:)
~Joshua
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"