> 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 _really_ failed to do it. Origin being 32V. Before both 4.0BSD and
SysIII, let alone 4.4BSD and SysV.
> > - 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.
See above. It had been there since _long_.
> 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.
Great. Let's _not_ bring BSD vs. Missed'em'Five flamewars here, OK?
Personally I got more than enough, erm, happiness when Sun switched from
sane system to the Bloat. YMMV.
[snip]
> 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).
Because some details of architecture are better than in all existing 4.4
derivatives.
[snip]
> > 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.
Exactly. So _when_ do you need an ability to delete file in /tmp and
ability to replace its contents doesn't satisfy you?
> > 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 it's a gratitious change in permissions semantics (aside of
many other reasons). You just do not run around changing this stuff
without a very good case. _Really_ good one. Same as above. Show me an
example of program that actually uses this detail of SysV semantics of
IS_VTX. Until then... If we are going to play the games with statistics -
fine, count the processors running the systems with current Linux
semantics. _Including_ Linux, please.
The bottom line:
a) this is historical behaviour of UNIX since late 70s.
b) most of the existing UNIX[1] installations does exactly that.
c) it is compliant with POSIX.
d) changing it is unlikely to buy you anything - I'm yet to see a program
that relies on the alternative behaviour.
e) compliance to SVr4 never was a stated goal (see (c)).
[1] Including Linux. And in the next couple of years the share is going to
increase, _both_ from Linux and *BSD sides.
-
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/