|
Home > Archive > Debian Developers > January 2006 > /run vs. /lib/run
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Thomas Hood 2005-12-19, 6:04 pm |
| Any other defenders of /lib/run? Of /run?
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2005-12-19, 6:04 pm |
| Thomas Hood <jdthood@yahoo.co.uk> writes:
> Any other defenders of /lib/run? Of /run?
/run makes much more sense to me. /lib/run just seems unbearably ugly,
not to mention that it would be kind of nice to have a read-only /lib be a
possibility for a variety of reasons (yes, I know, module dependencies
make this hard).
Perhaps this is a bad idea (or perhaps this is even how it's already
done), but given the very limited number of things that would have to use
/run, would it be possible to write them all to use /var/run if it's
available and only if it's not, fall back on /run? That way, /run could
be created during the boot process, then moved to /var/run and removed
again once /var is available, making it a transient aspect of the boot
process and not hanging around as a new top-level directory.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Gabor Gombas 2005-12-19, 8:51 pm |
| On Mon, Dec 19, 2005 at 11:41:26AM -0800, Russ Allbery wrote:
> Perhaps this is a bad idea (or perhaps this is even how it's already
> done), but given the very limited number of things that would have to use
> /run, would it be possible to write them all to use /var/run if it's
> available and only if it's not, fall back on /run? That way, /run could
> be created during the boot process, then moved to /var/run and removed
> again once /var is available, making it a transient aspect of the boot
> process and not hanging around as a new top-level directory.
/run cannot be created during the boot process since it may be needed
before / is writeable. Also, if /run does not exist when the system is
up, the admin may think that the name is available and put real data
there (or just simply expect it to be present once he/she mkdir'ed it),
so removing it is dangerous.
What may be possible (and I'd prefer) is to use a name like /.run, but
AFAIK there are people here who dislike dot-names in /.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2005-12-19, 8:51 pm |
| On Mon, Dec 19, 2005 at 08:12:37PM +0100, Thomas Hood wrote:
> Any other defenders of /lib/run? Of /run?
Heh. You know, you could've just said "Yes, my heart is set on /run"
right at the start and saved us all a lot of trouble...
Cheers,
aj
| |
| Peter Samuelson 2005-12-20, 2:51 am |
|
[Thomas Hood]
> Any other defenders of /lib/run? Of /run?
/etc/run. mtab and resolv.conf and the lvm1 state files and so forth
always lived in /etc before, so there's continuity.
| |
| Anthony Towns 2005-12-20, 2:51 am |
| On Mon, Dec 19, 2005 at 11:41:26AM -0800, Russ Allbery wrote:
> Thomas Hood <jdthood@yahoo.co.uk> writes:
> /run makes much more sense to me. /lib/run just seems unbearably ugly,
> not to mention that it would be kind of nice to have a read-only /lib be a
> possibility for a variety of reasons
/., /bin, /etc, /lib, and /sbin all need to be on the same filesystem (or
at least all mounted by the time init is invoked). There's no practical
difference between expecting /run and /lib/run being writable -- you're
either expecting / to be writable, or you're using it as the mountpoint
for a new writable filesystem. Also, /dev/shm can already be an example
of a rw filesystem mounted on top of a readonly subdirectory on the root
filesystem, eg.
Pros and cons of /run:
+ already implemented
+ name and purpose roughly match /var/run
- new directory in /
- promotes the files it contains from /etc etc into first class
citizens, overstating their importance
- provides a more prominent namespace than /var/run, encouraging misuse
Pros and cons of /lib/var or /lib/run:
+ use of /lib corresponds with use of /usr/lib and /var/lib
+ keeps files out of the way
- have to introduce a separate dir to separate behaviour corresponding
to /var/lib from behaviour corresponding to /usr/lib
Pros and cons of /var/run:
+ requires no software changes, just policy ones
- leaves the burden of ensuring /var is mounted early enough on
Debian users
There aren't any technical differences between the first two options.
Each of the solutions has a degree of ugliness -- in the first case,
the ugliness is in violating the "no new directories in /" rule and
making /run/ifstate seem more important than /etc/network/ifstate or
/var/run/ifstate would be; in the second, it's in having to introduce
a new subdirectory name to separate the variable parts of /lib out; in
the third, it's the system specific ugliness of having to ensure /var
is mounted early.
(TBH, I'd be much happier just making the technical changes necessary
to ensure /var is mounted early -- keeps the filesystem sane, and it's
just a simple matter of programming, rather than arguing over what's
ugly. If you need to use a tmpfs because you can't mount /var without
writing somewhere (to determine drivers, perhaps), it doesn't seem that
unreasonable to setup something like:
/: var/run -> /root/run
mount -t tmpfs tmpfs /root/run
/var: run -> /root/run
Local read-only / and NFS mounted /var might also require something
similar; but leaving the special cases for the systems that need it
seems a more reasonable idea than forcing it on everyone. Also, note
that onion mounts will probably eventually mean all this only needs to
be a temporary hack)
Cheers,
aj
| |
| Russ Allbery 2005-12-20, 2:51 am |
| Anthony Towns <aj@azure.humbug.org.au> writes:
> There aren't any technical differences between the first two options.
I agree with that.
> Each of the solutions has a degree of ugliness -- in the first case,
> the ugliness is in violating the "no new directories in /" rule and
> making /run/ifstate seem more important than /etc/network/ifstate or
> /var/run/ifstate would be; in the second, it's in having to introduce
> a new subdirectory name to separate the variable parts of /lib out; in
> the third, it's the system specific ugliness of having to ensure /var
> is mounted early.
That's not the ugliness that I care about with /lib/run; the uglyness that
I care about is that it's introducing /var content into /lib, which feels
like a serious violation of the spirit of the FHS to me (yes, we're
already violating the letter, but only because there's no /share and /lib
is essentially a merger of /lib and /share). /run is not equivalent to
/var/lib; it's equivalent to /var/run, which is not at all a lib directory
to me.
But it's all just aesthetics.
> (TBH, I'd be much happier just making the technical changes necessary to
> ensure /var is mounted early -- keeps the filesystem sane, and it's just
> a simple matter of programming, rather than arguing over what's ugly.
Yeah, I agree with this too.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2005-12-20, 2:51 am |
| On Mon, Dec 19, 2005 at 08:45:45PM -0800, Russ Allbery wrote:
> Yeah, I agree with this too.
So why don't we go with this? Thomas?
Here are the cases:
(a) /var on /, mounted rw during normal operation
(b) /var a local fs, separate to /
(c) / and /var separate NFS mounts
(d) / local, /var an NFS mount
(e) /var local, can't be mounted 'til a writable fs is available
For (a) you just need to wait until S10checkroot.sh has finished.
For (b) you need to wait until S35mountall.sh has finished.
For (d) and (e) you need special handling; using /run as a tmpfs and
setting up /var/run -> /run symlinks on both / and /var. That's pretty
special handling, and probably needs something like shared subtrees to
be done automatically at upgrade time (http://lwn.net/Articles/159077/).
For (c) you could either do the same handling as (d) and (e), or just expect
the admin to mount it rw as part of bootup.
As far as the "but programmers/admins might be confused" concern goes;
adding a brief /run/README at bootup seems feasible.
That'd mean:
/var is available after:
S10checkroot.sh (/var on rootfs)
S35mountall.sh (/var local)
S40hotplug (/var local, but requires hotplug drivers)
S45mountnfs.sh (/var on NFS not mounted before init)
/var/run is thus available after one of:
S10checkroot.sh
S35mountall.sh
S36mountvirtfs
And /var/run is used before /var is necessarily available by (on my system):
S39dns-clean
S40networking
S41hotplug-net
S43portmap
Hrm. Special casing in mountvirtfs and mountnfs.sh could be:
mountvirtfs:
if touch /var/run/.rw_var_run >/dev/null 2>&1; then
rm -f /var/run/.rw_var_run
elif [ "$EARLY_RUN_FS" ] && [ -d "$EARLY_RUN_FS" ]; then
echo "Mounting /var/run tmpfs on $EARLY_RUN_FS..."
mount -t tmpfs tmpfs "$EARLY_RUN_FS"
ln -s . "$EARLY_RUN_FS/run"
mount --bind "$EARLY_RUN_FS" /var
touch /var/.bind_var
else
echo "Error: no early writable filesystem available"
# ...
fi
mountnfs.sh:
if [ -e /var/.bind_var ]; then
rm -f /var/.bind_var /var/run
umount /var
fi
# ... mount -a
at which point you only need to mkdir $EARLY_FUN_FS and ensure /var/run is
a symlink to it when setting up that behaviour on upgrade. Alternatively
you could just make the directory and "mount --bind $EARLY_RUN_FS
/var/run" after mounting /var. (If $EARLY_RUN_FS is /run, you'd have to
work out in advance when it's needed so as not to add useless stuff to / when
it's not needed; adding a pointless dir to /etc or /lib would likely be okay
though)
Note that in that scenario programs are FHS compliant in that they only
access files throug the /var/run namespace, and if an admin prefers
/etc/run or /lib/run, it's just a matter of local configuration rather
than recompiling apps.
Cheers,
aj
| |
| Petter Reinholdtsen 2005-12-20, 8:05 am |
|
[Anthony Towns]
> So why don't we go with this? Thomas?
>
> Here are the cases:
>
> (a) /var on /, mounted rw during normal operation
> (b) /var a local fs, separate to /
> (c) / and /var separate NFS mounts
> (d) / local, /var an NFS mount
> (e) /var local, can't be mounted 'til a writable fs is available
>
> For (a) you just need to wait until S10checkroot.sh has finished.
> For (b) you need to wait until S35mountall.sh has finished.
But the potential users of this /run directory can not wait until
neither S10checkroot.sh nor S35mountall.sh for the directory to
appear. One user is bootlogd, needing before init is started to store
stats about the boot. That is before both these points in the boot.
Another is to update mtab, documenting every mount point as they are
mounted. This should hot have to wait until after /var/ is mounted.
A third use is read-only clients (LTSP/lessdisks), needing a place to
store things generated during boot (mtab, motd, etc). These work
around the issue by hacking the boot sequence quite a lot, but it
would be cleaner if no special handling is required.
As for /run vs /lib/run vs /somewhere on the root partition, I'm not
sure what I believe is the best option. I see several valid points
for moving it away from /, and several for keeping it there.
Friendly,
--
Petter Reinholdtsen
One of those
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Hood 2005-12-20, 8:05 am |
| > Heh. You know, you could've just said "Yes, my heart is set on /run"
> right at the start and saved us all a lot of trouble...
Let's just say that you aren't doing very well at reading my heart. 
Here's what I think about /run, or rather, R:
* A tmpfs R elegantly solves a handful of tricky problems.
* There are no good technical reasons not to implement R.
* There is no FHS prohibition of R.
* Other proposed solutions are technically inferior, mostly
because they are more complex.
* Various locations for R are possible and the choice ultimately
rests on aesthetic considerations about which people disagree.
Since the choice of location isn't that important, I'd have no
objection to putting R at /lib/run if there were something like a
consensus in favor of that location.
> So why don't we go with [making the technical changes necessary to
> ensure /var is mounted early]? Thomas?
>
> Here are the cases:
[...]
> For (d) and (e) you need special handling; using /run as a tmpfs and
> setting up /var/run -> /run symlinks on both / and /var. That's pretty
> special handling [...]
This is where I stop and ask why we would impose such a maintenance
burden on ourselves when there is an alternative that does not impose
such a burden.
The answer, I take it, is that the handful of programs, H, that
would use R can then use /var/run instead. The burden on H's
maintainers of knowing that their programs face special storage
problems is shifted onto the sysvinit maintainers and admins who
have to ensure that writable space is shoved under /var/run by
the time any of the H tries to write there.
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2005-12-20, 8:05 am |
| On Dec 20, Anthony Towns <aj@azure.humbug.org.au> wrote:
> (TBH, I'd be much happier just making the technical changes necessary
> to ensure /var is mounted early -- keeps the filesystem sane, and it's
> just a simple matter of programming, rather than arguing over what's
Me too.
--
ciao,
Marco
| |
| Gabor Gombas 2005-12-20, 8:05 am |
| On Tue, Dec 20, 2005 at 03:42:56PM +1000, Anthony Towns wrote:
> For (a) you just need to wait until S10checkroot.sh has finished.
> For (b) you need to wait until S35mountall.sh has finished.
I really like storing the fsck logs and that requires a writable place
before S10checkroot.sh finishes. Also, adding a new directory somewhere
seems better than making the boot process more complicated and more
rigid. Just make sure that new directory cannot be used after the boot
process finishes to catch abusers :-)
Gabor
--=20
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
| |
| Anthony Towns 2005-12-20, 5:59 pm |
| On Tue, Dec 20, 2005 at 12:10:07PM +0100, Thomas Hood wrote:
> * Other proposed solutions are technically inferior, mostly
> because they are more complex.
The other aspect is that /var's the place for stuff that varies during
normal use; introducing some other place for the same thing is redundant
and thus more complex.
> The answer, I take it, is that the handful of programs, H, that
> would use R can then use /var/run instead.
/var/run has always been the right place in the namespace; it's just
not been usable for technical reasons. If we fix the technical reasons,
all is good.
> The burden on H's
> maintainers of knowing that their programs face special storage
> problems is shifted onto the sysvinit maintainers and admins who
> have to ensure that writable space is shoved under /var/run by
> the time any of the H tries to write there.
Yup. Just as the burden of ensuring /usr is available is placed on
sysvinit maintainers and admins.
Cheers,
aj
| |
| Anthony Towns 2005-12-20, 5:59 pm |
| On Tue, Dec 20, 2005 at 12:01:44PM +0100, Petter Reinholdtsen wrote:
> [Anthony Towns]
> But the potential users of this /run directory can not wait until
> neither S10checkroot.sh
Uh, the new initscripts force them to wait until S36mountvirtfs...
> One user is bootlogd, needing before init is started to store
> stats about the boot. That is before both these points in the boot.
So how do you log the failure of mounting /run rw? Given this is supposed
to be a tmpfs, and not something permanent anyway, having bootlogd store
the output it's meant to be logging, and dump it to /var/log when it's
ready seems fine anyway. Adding that to init would even seem pretty
straightforward, along with an addition to telinit to, uh, tell init to
dump the logs somewhere.
There doesn't seem to be a bootlogd package?
> Another is to update mtab, documenting every mount point as they are
> mounted. This should hot have to wait until after /var/ is mounted.
Likewise, how do you document the mounting of /run in mtab?
Hrm, why don't we use /proc/mounts for mtab information, and have mount
store _only the extra information it needs_ in /var/run/mtab?
> A third use is read-only clients (LTSP/lessdisks), needing a place to
> store things generated during boot (mtab, motd, etc). These work
> around the issue by hacking the boot sequence quite a lot, but it
> would be cleaner if no special handling is required.
Sure, those were mentioned above (/ local, /var an NFS mount, or if
/var is a tmpfs or similar, / and /var local).
Cheers,
aj
| |
| Gabor Gombas 2005-12-20, 5:59 pm |
| On Tue, Dec 20, 2005 at 10:09:43PM +1000, Anthony Towns wrote:
> The other aspect is that /var's the place for stuff that varies during
> normal use; introducing some other place for the same thing is redundant
> and thus more complex.
The more I think about it, the usage of /run matches /tmp much better
than /var. It is for _temporary_ storage until a better place becomes
available.
If you want to tweak the boot process, then tweaking the mounting of
/tmp seems better than tweaking the mounting of /var.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Gabor Gombas 2005-12-20, 5:59 pm |
| On Tue, Dec 20, 2005 at 10:46:33PM +1000, Anthony Towns wrote:
> Likewise, how do you document the mounting of /run in mtab?
If you start with a read-only /, then no matter what you do, the first
mount command will not be recorded in mtab (unless you implement a mount
daemon that holds mtab in memory until it can write it somewhere).
> Hrm, why don't we use /proc/mounts for mtab information, and have mount
> store _only the extra information it needs_ in /var/run/mtab?
What keeps you from implementing it? :-)
A more technical problem: right now /etc/mtab presents a system-wide
global view, but the contents of /proc/mounts is already a per-process
thing. So if you want to use that, then you need a separate
/var/run/mtab.<pid> for every process (or at least one mtab file per
different namespace; which brings the question how do you detect if the
process changes its namespace).
Gabor
--=20
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
| |
| jdthood@yahoo.co.uk 2005-12-21, 5:58 pm |
| Anthony Towns wrote:
> On Mon, Dec 19, 2005 at 08:45:45PM -0800, Russ Allbery wrote:
>
> So why don't we go with this? Thomas?
The proposal looks like it could work. I would take the proposal,
simplify it (it can be made more complex later if there is a need for
more flexibility), and carry it out in at least two steps.
To simplify the first step we take the "early run fs" which is needed
in some cases, mount it unconditionally with a fixed fs type and at a
fixed location. This alone will be useful for several purposes.
Bind-mounting this directory under /var/run in a race-free manner can
be implemented in a second stage. Someone should submit a wish
report and provide a patch, plus testimony from maintainers who need
this enhancement and the reasons why they must be able to write to
/var/run/, per se, so early.
--
Thomas Hood ;)
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Petter Reinholdtsen 2005-12-21, 5:58 pm |
|
[Petter Reinholdtsen]
> One user is bootlogd, needing before init is started to store
> stats about the boot. That is before both these points in the boot.
I managed to write bootlogd when I intended to write bootchartd. That
is the package making statistics about the boot process.
[Anthony Towns]
> So how do you log the failure of mounting /run rw? Given this is supposed
> to be a tmpfs, and not something permanent anyway, having bootlogd store
> the output it's meant to be logging, and dump it to /var/log when it's
> ready seems fine anyway. Adding that to init would even seem pretty
> straightforward, along with an addition to telinit to, uh, tell init to
> dump the logs somewhere.
Sorry for the confusion. bootchartd is a shell script collecting
information into a tmpfs area during boot, and packing it together in
/var/log/ when the boot is over. It have no other way to store the
stats before other file systems are available but to put it in a tmpfs
area.
> Sure, those were mentioned above (/ local, /var an NFS mount, or if
> /var is a tmpfs or similar, / and /var local).
In LTSP, / is a readonly NFS mount (and /var is on /, also readonly).
Because of this, I did not consider / local and your description did
not match my understanding of LTSP.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Miquel van Smoorenburg 2005-12-21, 8:50 pm |
| In article <20051220120943.GA21166@localhost.localdomain>,
Anthony Towns <aj@azure.humbug.org.au> wrote:
>/var/run has always been the right place in the namespace; it's just
>not been usable for technical reasons. If we fix the technical reasons,
>all is good.
Well there is on more technical solution that might have been overlooked.
Why not create /var/run on the root file system even if /var is
mounted over it later on.
You can do something like:
- at bootup: mount -t tmpfs tmpfs /var/run
- S01, S02, S10 ..
- then:
cd /var/run
( cd /; mount -a )
if ! [ . -ef /var/run ]
then
mount --move . /var/run
fi
cd /
This works at least on 2.6. It keeps the shell process' working
directory in /var/run. Even if mount -a mounts something over it,
the shell process' working directory is still the tmpfs. Then you
just move the mount to the real /var/run .
This means that /var/run is always writable.
Postinst can create a /var/run "under" /var in a number of ways-
for example by mounting the root file system a second time somewhere,
or by calling a process that uses clone(CLONE_NEWNS), umounts /var
and mkdirs /var/run.
Mike.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joey Hess 2005-12-22, 2:59 am |
| Miquel van Smoorenburg wrote:
> mount --move . /var/run
mount --move only works in 2.6, not in 2.4. I think something similar
was suggested earlier in the thread and it is a nice solution for linux
2.6 systems.
--
see shy jo
| |
| Russell Coker 2005-12-22, 2:59 am |
| On Wednesday 21 December 2005 01:27, Gabor Gombas <gombasg@sztaki.hu> wrote:
> On Tue, Dec 20, 2005 at 10:09:43PM +1000, Anthony Towns wrote:
>
> The more I think about it, the usage of /run matches /tmp much better
> than /var. It is for _temporary_ storage until a better place becomes
> available.
Putting system directories under /tmp is a really bad idea, it opens
possibilities of race condition attacks by unprivileged users against system
processes. Generally for almost everything we should be looking to reduce
usage of /tmp rather than increase it.
I think that the only time /tmp should be used is when a user of the system
specifically requests that a file be stored there - then the user is making
the choice and race conditions are difficult to exploit as an attacker
usually doesn't know when a user is about to create a file or what the name
will be.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2005-12-22, 2:59 am |
| On Wed, Dec 21, 2005 at 04:14:14PM +0100, Petter Reinholdtsen wrote:
> Sorry for the confusion. bootchartd is a shell script collecting
> information into a tmpfs area during boot, and packing it together in
> /var/log/ when the boot is over. It have no other way to store the
> stats before other file systems are available but to put it in a tmpfs
> area.
Sure there are other ways: you can store it in a variable, eg:
while :; do
ps aux; netstat
sleep 1
done | (
out="X"
while read -r x; do
out="$(printf "%s%s\nX" "${out%X}" "$x")"
if [ -e dump-output ]; then
echo -n "${out%X}" >>dump-output
out=""
else
echo "Buffer size: $(echo $out | wc -c)"
fi
done
)
> In LTSP, / is a readonly NFS mount (and /var is on /, also readonly).
Uh, readonly /var isn't a supported configuration... Assuming you symlink
/var/lib/dpkg elsewhere, and don't fill up /var/cache/apt, it doesn't
seem like it'd need to be either?
Cheers,
aj
| |
| Anthony Towns 2005-12-22, 2:59 am |
| On Thu, Dec 22, 2005 at 01:37:11AM +0000, Miquel van Smoorenburg wrote:
> This works at least on 2.6. [...]
> This means that /var/run is always writable.
That's really quite nice. I wonder if requiring 2.6 is even much of a
problem -- 2.6.0 came out two years ago already and will be three by
the time etch is released, after all; and I assume the Hurd can deal
with this sort of issue trivially.
If "tmpfs swaps out" isn't enough to deal with screen and similar apps's
use of /var/run, it might be worth just moving them to /var/lib anyway.
Legacy 2.4 support could probably be arranged by using mount --bind
I guess, a la:
mount -t tmpfs tmpfs /etc/var-run
mount --bind /etc/var-run /var/run
...
mount --no-nfs -a
if ...; then mount --bind /etc/var-run /var/run; fi
...
mount -a
if ...; then mount --bind /etc/var-run /var/run; fi
Cheers,
aj
| |
| Miquel van Smoorenburg 2005-12-22, 7:50 am |
| In article <20051222064207.GC6455@localhost.localdomain>,
Anthony Towns <aj@azure.humbug.org.au> wrote:
>On Thu, Dec 22, 2005 at 01:37:11AM +0000, Miquel van Smoorenburg wrote:
>
>That's really quite nice. I wonder if requiring 2.6 is even much of a
>problem -- 2.6.0 came out two years ago already and will be three by
>the time etch is released, after all; and I assume the Hurd can deal
>with this sort of issue trivially.
Well, it appears there's MS_MOVE support in 2.4 too, since 2.4.19.
>If "tmpfs swaps out" isn't enough to deal with screen and similar apps's
>use of /var/run, it might be worth just moving them to /var/lib anyway.
Well actually, perhaps we should not even use mount --move. Just
copying the files is enough:
cd /var/run
( cd /; mount -a )
if ! [ . -ef /var/run ]
then
cp -a . /var/run
rm -rf ./* # (probably not needed)
umount -n -l .
fi
cd /
I tested this and it works fine. It's also a better solution, since
several packages contain directories in /var/run and ofcourse
they expect them to still exist after a reboot.
There's still a problem here - if /var/run is not overmounted,
how do you copy the contents of the current /var/run tmpfs
into the /var/run underneath ?
Perhaps something like this instead:
cd /var/run
( cd /; mount -a )
mount --move . /var/lib/earlyrun
cd /
cp -a /var/lib/earlyrun/. /var/run
umount -n -l /var/lib/earlyrun # we could try a few times
# without -l first to give
# daemons using early /var/run
# time to realize what happened
There are 2 conditions for programs using "early /var/run",
if they are running as a daemon (eg bootlogd):
1. Don't chdir into /var/run
2. Every so often (before every write), check if open file
handles for files in /var/run still correspond to the
actual file - compare fstat() and stat()
For things like pidfiles, resolv.conf, mtab etc it will just work.
The only thing is - this won't work for Debian/kFreeBSD. Someone
needs to write MS_MOVE support for the kFreeBSD kernel, I guess
Mike.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter Samuelson 2005-12-22, 7:50 am |
|
[Miquel van Smoorenburg]
> I tested this and it works fine. It's also a better solution, since
> several packages contain directories in /var/run and ofcourse they
> expect them to still exist after a reboot.
That's a bug, IMO - they should mkdir -p in their init scripts if
necessary. It's not like that's hard to do.
| |
| Henrique de Moraes Holschuh 2005-12-22, 7:50 am |
| On Thu, 22 Dec 2005, Miquel van Smoorenburg wrote:
> I tested this and it works fine. It's also a better solution, since
> several packages contain directories in /var/run and ofcourse
> they expect them to still exist after a reboot.
It is trivial to enhance these packages to support an ephemeral /var/run, if
it comes to that.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2005-12-22, 7:50 am |
| On Thursday 22 December 2005 20:58, "Miquel van Smoorenburg"
<miquels@cistron.nl> wrote:
> Well actually, perhaps we should not even use mount --move. Just
> copying the files is enough:
Copying the files won't work well if some of them are open at the time...
> There are 2 conditions for programs using "early /var/run",
> if they are running as a daemon (eg bootlogd):
>
> 1. Don't chdir into /var/run
Why not? mount --move works even when programs have their current directory
under the tree that's being moved.
> 2. Every so often (before every write), check if open file
> handles for files in /var/run still correspond to the
> actual file - compare fstat() and stat()
Not needed if mount --move is used instead of copying the files.
> The only thing is - this won't work for Debian/kFreeBSD. Someone
> needs to write MS_MOVE support for the kFreeBSD kernel, I guess
Or we can just require that kFreeBSD users not have a separate /var partition.
It's not as if Debian/kFreeBSD has many users.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2005-12-22, 5:59 pm |
| On Thu, Dec 22, 2005 at 09:58:37AM +0000, Miquel van Smoorenburg wrote:
> In article <20051222064207.GC6455@localhost.localdomain>,
> Anthony Towns <aj@azure.humbug.org.au> wrote:
> Well, it appears there's MS_MOVE support in 2.4 too, since 2.4.19.
Dude, so it does! Though in that case the mount manpage is wrong :-/
> Well actually, perhaps we should not even use mount --move. Just
> copying the files is enough:
That doesn't work if some app keeps the file open while /var is being mounted
though.
> I tested this and it works fine. It's also a better solution, since
> several packages contain directories in /var/run and ofcourse
> they expect them to still exist after a reboot.
I suppose that's true; but where's the difficulty in just initialising
/var/run on mount from some template for the programs that need it?
> The only thing is - this won't work for Debian/kFreeBSD. Someone
> needs to write MS_MOVE support for the kFreeBSD kernel, I guess
Can't kFreeBSD do transparent mounts anyway, and just mount a real
/var/run over the top of a tmpfs, leaving the tmpfs still visible?
On Thu, Dec 22, 2005 at 05:15:32AM -0600, Peter Samuelson wrote:
> [Miquel van Smoorenburg]
> That's a bug, IMO - they should mkdir -p in their init scripts if
> necessary. It's not like that's hard to do.
crack and crack-md5 are the only packages that include it in the deb;
the others already do it from the app, init script or postinst. But
we need to support third party apps too; so some special handling's
probably worthwhile.
Cheers,
aj
| |
| Russell Coker 2005-12-22, 8:51 pm |
| On Friday 23 December 2005 10:36, Gabor Gombas <gombasg@sztaki.hu> wrote:
> On Thu, Dec 22, 2005 at 05:18:43PM +1100, Russell Coker wrote:
>
> There are no user processes while scripts in /etc/rcS.d are running (not
There are processes run from rcS.d that use data written by untrusted user
processes, /etc/init.d/nviboot is one example.
There are also processes that read network data (which is potentially
hostile). /etc/init.d/ntpdate is one example.
> even crontabs, since cron itself has not been started yet). And after
> rc.S has finished, there is no justification to use /run. I do not see
> the problem with using /tmp for /run.
Why not use /home? Why not /root? Both of those directories will work and
should not be accessed from rcS.d, but for good design we don't want to do
this.
One of the problems with using a directory such as /tmp in a way other than
it's usual design under extraordinary circumstances is that people will see
the code in question, not understand the situation in which it was run, and
write other code that runs in multi-user mode which does similar things.
Another problem is that code which is written to run in single-user mode may
get changed to run in multi-user mode. A little thing like insecure
temporary file use in /tmp is not something that a typical sys-admin or
programmer is likely to notice when changing a program to run at a different
time.
> Moreover, I still mean to mount a temporary tmpfs over /tmp, so unless
> you explicitely do a "chmod a+w /tmp", normal user processes will not
> even be able to write to /tmp until the real /tmp is mounted (or if /tmp
> is on /, until the tmpfs is unmounted).
The default for a tmpfs is that the root directory is mode 1777, so if you
don't explicitly remove such access then it's granted. You might want to do
some tests of some of the things you are suggesting.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joey Hess 2005-12-23, 5:57 pm |
| Miquel van Smoorenburg wrote:
> Well, it appears there's MS_MOVE support in 2.4 too, since 2.4.19.
mount --move doesn't work here (2.4.27)
> Well actually, perhaps we should not even use mount --move. Just
> copying the files is enough:
Will that work for sockets?
--
see shy jo
| |
| Bernd Eckenfels 2005-12-23, 5:57 pm |
| In article <20051223194334.GC18512@kitenet.net> you wrote:
> Will that work for sockets?
or mmaped files? (however not sure if there are any on early boot).
Like /var/run/samba/*.tdb
Greetings
Bernd
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Weinehall 2005-12-26, 5:57 pm |
| On Mon, Dec 19, 2005 at 09:58:30PM -0600, Peter Samuelson wrote:
>
> [Thomas Hood]
>
> /etc/run. mtab and resolv.conf and the lvm1 state files and so forth
> always lived in /etc before, so there's continuity.
Oh please, let's not dump even more crap into /etc; it's ugly enough
as it is...
Regards: David Weinehall
--
/) David Weinehall <tao@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tim Cutts 2006-01-25, 2:58 am |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 22 Dec 2005, at 11:15 am, Peter Samuelson wrote:
>
> [Miquel van Smoorenburg]
>
> That's a bug, IMO - they should mkdir -p in their init scripts if
> necessary. It's not like that's hard to do.
Mailman is one such package (/var/lock in its case, but the
assumption is the same). When I suggested making that change to
Tollef, he wasn't very receptive. In my case I was mounting /var/run
and /var/lock as tmpfs filesystems all the time to reduce hard disk
access on a machine that was running all the time.
Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iQEVAwUBQ9cuXhypeFo2odvPAQKYFAf/YDufmFMXx4747K5ovHKKcgW7iGOVgsso
O5uys08TQ9OWJbvlskEgBW3+A5j5sSgO4tiTi8mk
i5w+iIj1pMzKY2aVbgA2i3I3
f4jZJG+Sc+AOf2WSGizIl7P7KWbuhOLoRFyXc5cx
8Z3i9IOjcd3d3s69GB1P4J1P
ZOl73D8aq2dQZrUl3SSgkGx/ 6xFiRq7coOhSPg3x111Pz20yx0h43Qm3aNh2sGgv
LKLmT8EU787LS9RGgnYQ5I0VWdu/IorytoWkZHabJhYUQSDaV1FAs08EuNGNajdA
s+g9SFP5RsHwcgNIMQZ+5LPunpHHs1YByGZ1KWWT
018MRLrzi+PkMg==
=bv/R
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Hood 2006-01-29, 9:38 pm |
| Peter Samuelson wrote:
> That's a bug, IMO - they should mkdir -p in their init scripts if
> necessary. It's not like that's hard to do.
Tim Cutts wrote:
> [...] In my case I was mounting /var/run
> and /var/lock as tmpfs filesystems all the time to reduce hard disk
> access on a machine that was running all the time.
Ubuntu is already mounting tmpfs's on /var/lock and /var/run. It's a
reasonable thing to do and we should support it. That means that
packages using these directories should create any subdirectories they
need.
Don't forget to set ownership and permissions.
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2006-01-29, 9:38 pm |
| On Wednesday 25 January 2006 22:40, Thomas Hood <jdthood@yahoo.co.uk> wrote:
> Tim Cutts wrote:
>
> Ubuntu is already mounting tmpfs's on /var/lock and /var/run. It's a
> reasonable thing to do and we should support it. That means that
> packages using these directories should create any subdirectories they
> need.
It's convenient that they did it first, now we can copy them with less
breakage expected.
Are there any other related things that we should be copying from them?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|