Messages in this thread | | | Date | Mon, 25 Oct 1999 01:37:25 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: buglet in ext2 sticky bit? |
| |
On Sun, 24 Oct 1999, Chuck Phillips wrote:
> 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/
| |