Re: Third /tmp location ? (and maybe a fourth too)
From: Andrew Johns (johnsa@kpi.com.au)
Date: 02/27/02
- Next message: Jason Stone: "Re: Third /tmp location ? (and maybe a fourth too)"
- Previous message: Roger Marquis: "Re: Third /tmp location ? (and maybe a fourth too)"
- In reply to: Roger Marquis: "Re: Third /tmp location ? (and maybe a fourth too)"
- Next in thread: Zvezdan Petkovic: "Re: Third /tmp location ? (and maybe a fourth too)"
- Reply: Zvezdan Petkovic: "Re: Third /tmp location ? (and maybe a fourth too)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 27 Feb 2002 11:04:11 +1100 From: Andrew Johns <johnsa@kpi.com.au> To: Roger Marquis <marquis@roble.com>
Roger Marquis wrote:
>>> File system full errors are typically caused by
>>> unnecessary partitioning. You rarely see them on
>>> single-partition systems. Creating symlinks or
>>> additional tmp directories to avoid the inevitable
>>> drawback of excess partitions is two bads, which don't sum
>>> to a good. Both also violate the KIS principle.
>>>
>> Unfortunately, as demonstrated in another reply, the
>> optimal partition scheme (/, /usr, /var) is preferred over
>> single partition schemes.
>>
>
> Preferred by who? Not by the majority of admins I've worked
> with over the past couple of decades. Neither is there any
> real gain afforded by a read-only /usr. /usr had to be
> partitioned years ago because it wouldn't fit on the root
> disk. With the introduction of 1GB disks there is no longer
> a good reason to partition /usr though some still
> rationalize the practice citing unsubstantiated benefits of
> read-only mounts vs read-only permissions.
It's called Defense in Depth, IIRC. Rather than "r/o mounts vs
r/o permissions", it should be "r/o mounts AND r/o perms" to
afford the greatest depth, although neither of these methods stop
anything once someone has root - it will just take them that
little bit longer to get around it (even if only seconds -
note:I'm in agreement that it's basically unsubstantiated,
however see below).
>
> Creating a partition for /var is also rarely necessary unless
> your applications require partitioning for performance ,
> pseudo-quotas, or they need more disk than the root volume
> provides.
>
I remember once seeing a system fill /var with a runaway process
that crashed overnight. Unfortunately all on one partition.
System emailed support, they dialled in to fix. Their dial-up
password had expired, they were prompted for new one, system
removed passwd file to update, runaway process saw the free space
and immediately filled it:
=> nowhere to write new passwd files!
=> passwd files empty
=> no users could log in.
=> no terminals logged in as root (policy), but there were 600
users already in...
I had to pull the plug to reboot it. This was for a bank and
they ran for a whole day (bank terminals stay logged into unix
account but with PICK application f/end) without any new logins.
Having something fill a separately mounted /var would never cause
this problem...
Just a few cents worth...
Cheers
AJ
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
- Next message: Jason Stone: "Re: Third /tmp location ? (and maybe a fourth too)"
- Previous message: Roger Marquis: "Re: Third /tmp location ? (and maybe a fourth too)"
- In reply to: Roger Marquis: "Re: Third /tmp location ? (and maybe a fourth too)"
- Next in thread: Zvezdan Petkovic: "Re: Third /tmp location ? (and maybe a fourth too)"
- Reply: Zvezdan Petkovic: "Re: Third /tmp location ? (and maybe a fourth too)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|