FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-12-2011, 07:21 PM
Roger Leigh
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, Apr 12, 2011 at 09:07:48PM +0200, Jan Hauke Rahm wrote:
> On Tue, Apr 12, 2011 at 07:47:35PM +0100, Roger Leigh wrote:
> > With the patch as it stands at present, RAMRUN is deprecated. /run
> > is always a tmpfs; RUN_SIZE will set its size, as before.
>
> Hmm, just thinking... vServers don't really allow mounting AFAIK as that
> would be the host's job. Wouldn't making /run a tmpfs in every case
> conflict here? Or am I jumping around nonsense now...?

I know little about vservers. How do they currently deal with
/dev/shm and /lib/init/rw?


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 04-12-2011, 07:30 PM
Jan Hauke Rahm
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, Apr 12, 2011 at 08:21:25PM +0100, Roger Leigh wrote:
> On Tue, Apr 12, 2011 at 09:07:48PM +0200, Jan Hauke Rahm wrote:
> > On Tue, Apr 12, 2011 at 07:47:35PM +0100, Roger Leigh wrote:
> > > With the patch as it stands at present, RAMRUN is deprecated. /run
> > > is always a tmpfs; RUN_SIZE will set its size, as before.
> >
> > Hmm, just thinking... vServers don't really allow mounting AFAIK as that
> > would be the host's job. Wouldn't making /run a tmpfs in every case
> > conflict here? Or am I jumping around nonsense now...?
>
> I know little about vservers. How do they currently deal with
> /dev/shm and /lib/init/rw?

Interesting question. Actually, in my setup, I don't see /dev/shm at
all and /lib/init/rw is a regular directory.

Hauke

--
.'`. Jan Hauke Rahm <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org
 
Old 04-12-2011, 08:02 PM
Roger Leigh
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, Apr 12, 2011 at 08:19:59PM +0100, Roger Leigh wrote:
> On Tue, Apr 12, 2011 at 07:44:54AM -0700, Steve Langasek wrote:
> > If the problem is that multiple tmpfs are mounted and
> > each can expand to half-of-RAM, either reduce the number of tmpfses
> > presented (as discussed), or limit the *whole* allocation for known mount
> > points to half-of-RAM and partition appropriately, or both.
>
> For this reason, I've adapted the patch to move /dev/shm to /run/shm;
> it's configurable whether this is a separate tmpfs mount, or simply
> a subdirectory of /run, and the size is also configurable as before
> (SHM_SIZE, with RAMSHM as the option to toggle the mounting). We
> could additionally allow /tmp to be moved under /run/tmp, so that
> all existing tmpfs mounts could share a single tmpfs (I haven't
> done this yet). Currently we mount a tmpfs on /tmp if RAMTMP=yes
> or root is mounted read-only, but we could move it under /run.

I should add here that while the other distributions have moved
/var/run and /var/lock under /run, they have not moved /dev/shm
or /tmp. I'm not sure what the consensus is on doing either of
these, so I haven't put either into the proposed patch yet.

I think the question to answer here is whether or not /dev/shm
and /tmp offer the same lifetime policies as /var/run and /var/lock,
and whether or not they logically fit under the same heirarchy.
The first is clearly the case: they can all be on tmpfs. Whether
they logically fit is not so clear.

I think that if we have /run/lock, /run/shm makes sense (how different
are locks and POSIX semaphores? They are just a different type of
lock (broadly). And shared memory is ephemeral state, just like
samba's state etc.). So I would argue that it does fit. But this
isn't a universally held opinion. Is there any rationale against
doing this?

I'm not as sure about /run/tmp, though all the files under /run
are strictly temporary, they are pretty much all system files
rather than being owned by users (though /run/lock and /run/shm
would be user-writable; however, there are proposals to restrict
access to /lock as on Fedora).


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 04-12-2011, 08:08 PM
Tollef Fog Heen
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

]] Roger Leigh

| I think that if we have /run/lock, /run/shm makes sense (how different
| are locks and POSIX semaphores? They are just a different type of
| lock (broadly). And shared memory is ephemeral state, just like
| samba's state etc.). So I would argue that it does fit. But this
| isn't a universally held opinion. Is there any rationale against
| doing this?

/dev/shm is POSIX shared memory, not just semaphores, afaik?

| I'm not as sure about /run/tmp, though all the files under /run
| are strictly temporary, they are pretty much all system files
| rather than being owned by users (though /run/lock and /run/shm
| would be user-writable; however, there are proposals to restrict
| access to /lock as on Fedora).

I'd rather not make /tmp a tmpfs, and there's no reason for it to live
under /run. It might also reasonably be namespaced for different users
and so on, so moving it somewhere else than /tmp is, IMO, silly.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8739lns05d.fsf@qurzaw.varnish-software.com">http://lists.debian.org/8739lns05d.fsf@qurzaw.varnish-software.com
 
Old 04-12-2011, 08:22 PM
Philipp Kern
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On 2011-04-12, Roger Leigh <rleigh@codelibre.net> wrote:
> Having multiple tmpfses with the kernel defaults means that a user or
> badly written program could intentionally or accidentally lock up the
> machine by using all available memory by filling up one or more of the
> tmpfses. And the majority /are/ user writable by default, even /run
> (via /var/lock, which is not a separate mount by default--maybe it
> should be?). /dev/shm is user writable, /tmp is user writable.

How is that different from lock-ups due to fork bombs? If the admin cares, he
can still fence his users. (Like DSA do on their machines by setting a sane
tmpfs size limit.)

Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrniq9d38.phd.trash@kelgar.0x539.de">http://lists.debian.org/slrniq9d38.phd.trash@kelgar.0x539.de
 
Old 04-12-2011, 08:35 PM
Luca Capello
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

Hi there!

On Tue, 12 Apr 2011 20:47:35 +0200, Roger Leigh wrote:
> On Tue, Apr 12, 2011 at 08:12:21PM +0200, Luca Capello wrote:
>> On Tue, 12 Apr 2011 13:38:03 +0200, Roger Leigh wrote:
>> > Josh Triplett suggested that we could use a single tmpfs on /run and
>> > have the rest as symlinks into /run, with potentially a separate
>> > tmpfs for user-writable filesystems to prevent a user DoS. This idea
>> > does have merit, and we could make it the default. We currently do
>> > this for /var/lock (/run/lock), which can be mounted as a separate
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > tmpfs on /run/lock if RAMLOCK is set in /etc/defaults/rcS.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^
>>
>> Do you mean that the meaning of RAMLOCK has completely changed?
>> Currently, `man rcS` gives:
>>
>> RAMLOCK
>> Make /var/lock/ available as a ram file system (tmpfs).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^
[...]
>> I consider completely changing it a serious bug, may I suggest
>> deprecating it completely and adding a new variable instead? I guess
>> the same should be applied to RAMRUN, i.e. simply deprecate it.
>
> With the patch as it stands at present, RAMRUN is deprecated. /run
> is always a tmpfs; RUN_SIZE will set its size, as before.

Fair enough and, FWIW, fully agree.

> RAMLOCK is unchanged, except for the fact that it's mounted on
> /run/lock rather than /var/lock.

No, /var/lock changed *substantially*, given that it is now *by default*
(on) a tmpfs, regardless if RAMLOCK is set or not. Which means that
RAMLOCK as it was explained is useless, thus my question about your
words underlined above: "which can be mounted as a separate tmpfs on
/run/lock if RAMLOCK is set in /etc/defaults/rcS".

I do not have any idea which variable could be straightforward,
something like LOCK_OWN_TMPFS...

> Likewise, LOCK_SIZE is unchanged in its meaning.

Again, I found it changed: how can you define LOCK_SIZE if /run/lock is
on the same tmpfs than /run?

> We could introduce new variables for /run such as RUNLOCK, but given
> that it does exactly what it used to do, I don't think it gains us
> anything.

Fully agree, and FWIW it was not what I was asking for ;-)

Thx, bye,
Gismo / Luca
 
Old 04-12-2011, 09:26 PM
Roger Leigh
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, Apr 12, 2011 at 10:08:30PM +0200, Tollef Fog Heen wrote:
> ]] Roger Leigh
>
> | I think that if we have /run/lock, /run/shm makes sense (how different
> | are locks and POSIX semaphores? They are just a different type of
> | lock (broadly). And shared memory is ephemeral state, just like
> | samba's state etc.). So I would argue that it does fit. But this
> | isn't a universally held opinion. Is there any rationale against
> | doing this?
>
> /dev/shm is POSIX shared memory, not just semaphores, afaik?

Yes, it's used for both.

> | I'm not as sure about /run/tmp, though all the files under /run
> | are strictly temporary, they are pretty much all system files
> | rather than being owned by users (though /run/lock and /run/shm
> | would be user-writable; however, there are proposals to restrict
> | access to /lock as on Fedora).
>
> I'd rather not make /tmp a tmpfs, and there's no reason for it to live
> under /run. It might also reasonably be namespaced for different users
> and so on, so moving it somewhere else than /tmp is, IMO, silly.

One reason for doing this is to have a single writable mount on the
system, which might be useful for tiny systems with minimal
resources, where root is r/o. On such a system, it might be useful
to pool the limited writable space (which might not be a tmpfs).

This isn't a common use case, but one of the considerations in the
patch is to make read-only root possible, and since one of the
changes is to automatically mount a tmpfs on /tmp if root is
read-only, I thought it was worth asking the question if it could be
shared with the existing tmpfs filesystems on the system. While a
tmpfs on /tmp isn't going to be the default, the patch does add
support for it (RAMTMP).


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 04-12-2011, 09:32 PM
Roger Leigh
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, Apr 12, 2011 at 08:22:00PM +0000, Philipp Kern wrote:
> On 2011-04-12, Roger Leigh <rleigh@codelibre.net> wrote:
> > Having multiple tmpfses with the kernel defaults means that a user or
> > badly written program could intentionally or accidentally lock up the
> > machine by using all available memory by filling up one or more of the
> > tmpfses. And the majority /are/ user writable by default, even /run
> > (via /var/lock, which is not a separate mount by default--maybe it
> > should be?). /dev/shm is user writable, /tmp is user writable.
>
> How is that different from lock-ups due to fork bombs? If the admin
> cares, he can still fence his users. (Like DSA do on their machines
> by setting a sane tmpfs size limit.)

It's something which is entirely preventable, and while it's possible
for sysadmins to set the limits to something sane, I would really
like to have something sane by default when this is possible. And
for some of the filesystems in question, this is totally safe to do.
Others like /var/run do vary somewhat more, but it should still be
possible to do better than existing practice.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 04-12-2011, 09:42 PM
Roger Leigh
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, Apr 12, 2011 at 10:35:37PM +0200, Luca Capello wrote:
> Hi there!
>
> On Tue, 12 Apr 2011 20:47:35 +0200, Roger Leigh wrote:
> > On Tue, Apr 12, 2011 at 08:12:21PM +0200, Luca Capello wrote:
> >> On Tue, 12 Apr 2011 13:38:03 +0200, Roger Leigh wrote:
> >> > Josh Triplett suggested that we could use a single tmpfs on /run and
> >> > have the rest as symlinks into /run, with potentially a separate
> >> > tmpfs for user-writable filesystems to prevent a user DoS. This idea
> >> > does have merit, and we could make it the default. We currently do
> >> > this for /var/lock (/run/lock), which can be mounted as a separate
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> > tmpfs on /run/lock if RAMLOCK is set in /etc/defaults/rcS.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^
> >>
> >> Do you mean that the meaning of RAMLOCK has completely changed?
> >> Currently, `man rcS` gives:
> >>
> >> RAMLOCK
> >> Make /var/lock/ available as a ram file system (tmpfs).
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^
> [...]
> >> I consider completely changing it a serious bug, may I suggest
> >> deprecating it completely and adding a new variable instead? I guess
> >> the same should be applied to RAMRUN, i.e. simply deprecate it.
> >
> > With the patch as it stands at present, RAMRUN is deprecated. /run
> > is always a tmpfs; RUN_SIZE will set its size, as before.
>
> Fair enough and, FWIW, fully agree.
>
> > RAMLOCK is unchanged, except for the fact that it's mounted on
> > /run/lock rather than /var/lock.
>
> No, /var/lock changed *substantially*, given that it is now *by default*
> (on) a tmpfs, regardless if RAMLOCK is set or not. Which means that
> RAMLOCK as it was explained is useless, thus my question about your
> words underlined above: "which can be mounted as a separate tmpfs on
> /run/lock if RAMLOCK is set in /etc/defaults/rcS".
>
> I do not have any idea which variable could be straightforward,
> something like LOCK_OWN_TMPFS...
>
> > Likewise, LOCK_SIZE is unchanged in its meaning.
>
> Again, I found it changed: how can you define LOCK_SIZE if /run/lock is
> on the same tmpfs than /run?

If you set RAMLOCK=yes, then /run/lock is a *separate* tmpfs
of size LOCK_SIZE, *exactly* like the /var/lock tmpfs mount
(it's the same code with s/var/run/g). So the actual behaviour of this
option is entirely unchanged bar the switch from /var/lock to
/run/lock.

So by default, /run and /run/lock are on the same tmpfs. But
if you set RAMLOCK=yes, you'll get a second tmpfs mounted on
/run/lock. So yes, /run/lock will always be on a tmpfs filesystem,
that's obviously the main point of the patch. But the sysadmin can
configure the size of /run/lock separately should they choose to do so
(especially since it's user-writable by default).


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 04-13-2011, 08:29 AM
Stig Sandbeck Mathisen
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

Roger Leigh <rleigh@codelibre.net> writes:

> One reason for doing this is to have a single writable mount on the
> system, which might be useful for tiny systems with minimal resources,
> where root is r/o. On such a system, it might be useful to pool the
> limited writable space (which might not be a tmpfs).

Could this case be handled better by the fsprotect package?

--
Stig Sandbeck Mathisen <ssm@debian.org>
 

Thread Tools




All times are GMT. The time now is 12:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org