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

Re: 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:
>> 		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

Attachment: pgpT2H6S8eE8P.pgp
Description: PGP signature

Reply to: