Hash: SHA1

At some point hitherto, [EMAIL PROTECTED] hath spake thusly:
> On Wed, 24 Jul 2002, at 10:55am, [EMAIL PROTECTED] wrote:
> > I don't disagree with any of that, I was merely stating that it's an
> > amusing read.
>   You forget there is a real person on the other end of it.  I have been the
> object of that kind of abuse too many times to find it amusing.  :-(

All I can say in my defense is, frustration + liquor != happy bug
reporting...  I actually do agree with you.

> > ... espoused by Evi Nemeth, et al, in the UNIX/Linux System
> > Administrator's Handbook series.  RH violates these basic practices with
> > their configurations many times.
>   Heh.  My take on the same thing was that USAH didn't "get" many things
> about Linux and GNU.  :-)  The biggest being: GNU's Not Unix.

When you say this, it makes me think that you don't get GNU.  GNU's
*not* Unix.  But it was always intended to work like Unix, by and
large.  While it's true that:

> There are times where Red Hat (and others) have decided not to
> perpetuate certain braindamages from traditional Unix.

That doesn't mean that they haven't introduced their own brain damage,
which can sometimes be as bad or worse than the commercial Unixen.

> A good example is the whole /var/spool/mail thing.  Historical Unix made
> that directory world writable with the sticky bit set.  The major reason for
> that was locking -- programs created lock files in that directory to reserve
> write access to a mailbox.  Of course, it is also a rather big security
> exposure, especially on a large, multi-user system.

It doesn't have to be, and it shouldn't be.  I was (initially) not
aware that Linux allowed arbitrary users to create hard links to any
other arbitrary user's files, despite any ownership and permissions on
the original file.  This is the worst of the problem.  I brought this
issue up on LKML, and finally AC made the concession that there should
at least be a mount option to prevent that behavior.  Allowing it is,
in most cases, just plain stupid.  This is a case where the Linux
developers did NOT erase a brain damage, in the name of making it work
like traditional Unixen.  It was pointed out that neither POSIX nor
SUS require this behavior, and that seemed to sway some opinions...

Beyond that though, the security implications are fairly minor.
Proper implementation and enforcement of policy, and attention to
permissions on created files will mitigate or eliminate most of them.

> Red Hat went to the trouble of making sure all the mail programs on
> their system use kernel-level locking (flock/fcntl), eliminating the
> need for that long-standing braindamage.  And I say: Good!

Sort of...  Traditionally, the only method of locking guaranteed to
work across Unix systems was to create a unique file, then link(2) the
well-known lock file to it.  If the link() succeeds, you have your
lock.  If it doesn't, try, try again.

Kernel level locking especially does not work particularly well with
NFS on many platforms, but ironically it's the ONLY method that works
reliably with NFS on Linux.  So if you need to interoperate via NFS
with multiple platforms (something that is done in many environments),
you're pretty much guaranteed that your locking mechanism will break
somewhere, no matter what you pick...  You can compensate by choosing
to use multiple methods, but then you have a race condition...

OTOH, it's also my opinion that you should *never* make your mail
spool available via NFS.  Ok, maybe not never, but I can't imagine
wanting to work in an environment where doing so can be argued to
"make sense."  Between the locking issues and the security
implications, it's just a bad, bad idea.

- -- 
Derek Martin               [EMAIL PROTECTED]    
- ---------------------------------------------
I prefer mail encrypted with PGP/GPG!
GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
Learn more about it at http://www.gnupg.org
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.

Reply via email to