Date: Sun, 14 Mar 1999 13:46:13 -0600 (CST) From: James Wyatt <jwyatt@RWSystems.net> To: freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <Pine.BSF.4.05.9903141228350.5759-100000@kasie.rwsystems.net> In-Reply-To: <Pine.BSF.3.96.990314121837.5121C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Mar 1999, Robert Watson wrote:
> On Sun, 14 Mar 1999, Peter Jeremy wrote:
> > Normal users shouldn't have write permission anywhere on a partition
> > containing system binaries - this also removes the problem. (Note
> > that /usr/tmp is accessible only by root under FreeBSD).
>
> But many common FS arrangements do use the same partition for a
> world-writable directory and the binaries. For example:
>
> /var on /usr/var (/var has /var/tmp)
> /usr/local/ on /usr (The tex port requires a world-writable temp
> directory)
> /tmp on / (/sbin is usually on /; default install I believe)
> /home on /usr/home (default install I believe)
For /tmp and /home, these are best as separate filesystems if you have
regular users, IMHO. For /var/tmp, maybe there is a good use for a
symlink?
I'm sorry, but I consider making a world writable directory under
/usr/local/ simply *broken*. A symlink would suffice here until the port
or package or application folks could be made aware of the sysadmin
implications of this behavior (the sudo folks got it right).
> I like the idea of the FS namespace having consistent
> semantics--counter-intuitive security behavior like "the system is
> relatively secure as long as you don't partition the system in any way
> that allows these files to be on the same partition as these files..."
> seems best to be avoided.
Yes, but it's portable. 8{) Some of us have been doing it since we had BSD
on the VAXen. Some commercial Unixes (Uni?) ship that way. I also like the
idea of a small root filesys and extra /tmp filesys as it moves us closer
to a RO root filesys. It makes root backups quicker. In fact, it would
be a nice change to the 'auto defaults' disk partitioning portion of our
install.
> I think hard links are neat, et al, but I really don't think they add any
> new useful functionality above symlinks, and they can certainly introduce
> new problems. They save a little disk space here and there (as long as
> you don't recursive move anything)...
Symlinks also introduce their own problems. They can point to *nothing*
when hard links can't. (esp. post-fsck!) Symlinks also burn inodes and
more filesystem space. They are a *real* headache and performance sink on
news filesystems. Of course, having worked on *nix systems that had hard
links, but no symlinks, I may be biased... I also have used them to do
filesystem databases (each directory is an index with a link to the real
data nugget. Fast, but table-joins by comparing inodes was tough... 8{(
Anyone else remember the UseNet wag who said "Symlinks can turn your
filesystem tree into a bramblebush."? Rich Salz, perhaps? - Jy@
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9903141228350.5759-100000>