Re: uuidd: move uuidd files from /var/lib/libuuid to /var/run/uuidd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mike Frysinger <vapier@xxxxxxxxxx> wrote:
> On Monday 29 June 2009 21:33:44 Theodore Ts'o wrote:
> > There was a very good reason why uuid state files were in
> > /var/lib/libuuid instead of /var/run/uuidd.  Some distributions wipe all
> > of /var/run on reboot.  The problem is for security reasons uuidd has to
> > run as the libuuid user --- and the problem is directory needs to be set
> > up correctly with the right permissions so it can written by the setuid
> > libuuid daemon.  So if you are going to move files into /var/run/uuidd,
> > on at least some distributions, util-linux-ng will also have to provide
> > init scripts to set up the directory correctly each time at boot.
> >
> > By placing those files in /var/lib/libuuid, it avoided this problem.
> 
> what exactly is the purpose of these state files ?  are they supposed to be 
> created fresh at every reboot, or are they expected to live across reboots ?  
> i think that is the question which should determine /var/run vs /var/lib, not 
> init.d issues.

We are speaking of 3 different files here:
1. PID file for uuidd
2. request socket for uuidd
3. the clock.txt state file

According to FHS PID files and sockets *must* be put in /var/run.
That's why I changed the default, when I packaged this for SUSE (speaking
explicitly in the past since for some reason I no longer work there).

The state file clock.txt should of course be kept in /var/lib, because
it should remain valid after a reboot.

> > A similar issue is why the clock state file is in /var/lib instead of
> > /var/run.
> 
> the clock state file lives in /var/lib because it is supposed to stick around, 
> not get punted.  not really a permission issue in any way.  FHS specifically 
> states that /var/run should be cleaned/truncated while /var/lib is for state 
> data that is supposed to be retained across runs.

I agree.

Matthias

--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux