lkml.org 
[lkml]   [1999]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: buglet in ext2 sticky bit?
>> In this case, SVr4 "sticky dir" semantics allow/encourage least-privilege
>> design. Linux semantics currently don't.

> Since 4BSD derivatives do not have this semantics it's pointless...

Thanks for pointing out the origin of the only-UID-matters sticky dir
semantics. I failed to check the BSD 4.4 manuals. Mea culpa.

> - you will get a non-portable code that can be very hard to fix. IOW,
> anything that relies on such property is broken by design.

o Having the sticky bit on a directory mean *anything* is non-portable.
This is as good an argument against BSD 4.4 semantics as it is against
SVr4 semantics. To my knowledge, the sticky bit on a directory was first
significant on SunOS 4.1. Before that, it had no meaning at all. No
matter what semantics (including nothing), sticky dirs are not portable.

o It is precisely because of Linux's relative compatibility with POSIX,
SVr4 and XPG that I use and professionally recommend Linux instead of
BSD. POSIX, SVr4 and XPG are the vendor-neutral published standards that
the current commercial UNIXs try to implement. This is a big selling
point for anyone migrating from, or interoperating with, current
commercial UNIX dialects like Solaris, HPUX, etc. It is precisely
because of BSD's relative indifference to SVr4, POSIX and XPG that I have
never professionally recommended it. This is also why compatibility with
BSD, _by itself_, is of little value to me or most of my clients. This
is also why you'll see more commercial software ported to Linux than BSD
even though BSD has been available a lot longer.

o If you compare money spent, numbers of CPUs, number of users, cumulative
CPU power, etc., I'd bet SVr4 derivatives are a *lot* more common than
BSD derivatives. Even OSF ultimately adopted SVr4 "lite" as a base
system. If portability is the issue, go with SVr4 (and POSIX and XPG as
applicable) semantics when BSD is different unless there's a good reason
not to.

o If Linux were more like BSD, why should I prefer it over BSD? I've got
source for BSD and it hasn't changed much over the last ten years (i.e.,
more stable, easier to learn and stay current).


>> If you already can write to a file, being able to actually delete it isn't
>> likely to create an *additional* security hole. Exception: If the file's
>> existence is used merely as a semaphore and the contents ignored -- but
>> then there is the obvious possibility of not making the file writable by
>> the world when it is created.

> The same reasoning shows that in 99% of cases you simply will not need
> this feature.

Huh? I expect the more common case is that the contents of the file
matter, in which case SVr4 semantics make much more sense. Being able to
completely replace the content of a file, but not actually delete it, is
just plain silly 99% of the time. File-based semaphores are the possible
exception. (Even that is a stretch, IMHO.) I only acknowledged the
exception. That's not the same as suggesting the exception is the common
case.

> Playing with permissions semantics (_removing_ restrictions at that) just
> because someday somebody might want to write (unspecified) non-portable
> code... Yuck.

Q: If removing restrictions is intrinsicly bad, then why not drop GIDs and
world-access altogether? Just base all access on the UID. If it's good
for /tmp, why not the rest of the file system?

A: Because GIDs and world access allow more *useful* behavior and make
secure programming more convenient -- while not preventing UID-only
access if you want or need it.

Hope this explains,
Chuck

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.355 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site