gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/20/88)
In article <118@hudson.Morgan.COM> frank@Morgan.COM (Frank Wortner) writes: >In article <8910@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >}Inode permissions apply to the contents of the inode, not to >}links to it (which are contained in other inodes). >Perhaps I've failed to understand what you wrote. I've always thought that >non-symbolic links were directory entries pointing to the *same* inode, and >that any permissions (read, write, and execute of the underlying object) >were shared by all links. No, the link can be altered independently of permissions on the inode to which it is a link. The link is an object (directory entry) that is a piece of another object (the directory) separate from the inode object. The inode itself can be read, written, executed, etc. only in accordance with the permissions attached to IT, whereas links to the inode are controlled by the permissions attached to their containers (directories). The one extra wrinkle is that space used by an inode is reclaimed when it becomes totally inaccessible (last link to it is removed). All implementations of "symbolic links" that I know of are broken in this regard; even though symbolic links to an inode exist, the inode will vanish when all its "hard" links are removed (and the last open file table entry associated with it is closed). A utility such as "rm" COULD perform extra checks based on the inode permissions. In fact the 4.nBSD "rm" does this ("override permissions on xxx?") and it is EXTREMELY annoying.
jbs@fenchurch.mit.edu (Jeff Siegal) (11/21/88)
In article <8941@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >A utility such as "rm" COULD perform extra checks based on the inode >permissions. In fact the 4.nBSD "rm" does this ("override permissions >on xxx?") and it is EXTREMELY annoying. It is so annoying because the check is based on write access to the file, which has very little, if anything to do with the operation of deleting the file. If there was a delete permission bit (this was the original point, I believe), and some one had specifically turned it off, you might actually want to think twice about deleting the file. Jeff Siegal
jfc@athena.mit.edu (John F Carr) (11/21/88)
In article <8941@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >All implementations of "symbolic links" that >I know of are broken in this regard; even though symbolic links to an >inode exist, the inode will vanish when all its "hard" links are >removed (and the last open file table entry associated with it is closed). I don't count this as a bug; it can be quite useful. For example, hard links must be to the same device. An implementation of symbolic links that had the destiniation be an inode would be indistinguishable from a hard link (at least in 4.3, symbolic links point to filenames [or, in fact, any string that could possibly be a filename]). There is no way to guarantee that all symbolic links to a filename are on mounted filesystems, so it is not reasonable to have their existence influence unlinking. -- John Carr "When they turn the pages of history, jfc@Athena.mit.edu When these days have passed long ago, bloom-beacon! Will they read of us with sadness athena.mit.edu!jfc For the seeds that we let grow?" --Neil Peart
guy@auspex.UUCP (Guy Harris) (11/22/88)
>A utility such as "rm" COULD perform extra checks based on the inode >permissions. In fact the 4.nBSD "rm" does this ("override permissions >on xxx?") and it is EXTREMELY annoying. So does the System V Release 3.1 one, and, if I remember correctly, so did the V7 and perhaps even the V6 one; one can hardly flame Berkeley for this one.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/22/88)
In article <480@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
->A utility such as "rm" COULD perform extra checks based on the inode
->permissions. In fact the 4.nBSD "rm" does this ("override permissions
->on xxx?") and it is EXTREMELY annoying.
-So does the System V Release 3.1 one, and, if I remember correctly, so
-did the V7 and perhaps even the V6 one; one can hardly flame Berkeley
-for this one.
But I think it was Berkeley who decided to prompt with a completely
misleading question! I've known others who disliked this.dhesi@bsu-cs.UUCP (Rahul Dhesi) (11/23/88)
In article <8956@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >But I think it was Berkeley who decided to prompt with a completely >misleading question! I've known others who disliked this. In System V, the question no verb. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/23/88)
In article <8941@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <118@hudson.Morgan.COM> frank@Morgan.COM (Frank Wortner) writes: >>In article <8910@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>}Inode permissions apply to the contents of the inode, not to >>}links to it (which are contained in other inodes). >>Perhaps I've failed to understand what you wrote. I've always thought that >>non-symbolic links were directory entries pointing to the *same* inode, and >>that any permissions (read, write, and execute of the underlying object) >>were shared by all links. >No, the link can be altered independently of permissions on the inode >to which it is a link. This is a confusion in understanding of what is meant by "the link". Most people, including frank@Morgan.COM, seem to think of "the link" as the object named, the file containing data. That is indeed one object, with permissions, data, etc. Gurus like Doug have much understanding of the reality underlying this, but sometimes forget to explain, that the "link" is just the name. It has itself no inherent permissions et al. The file or other object so named has the permissions. The name does not. The implementation of the name as a series of directory entries implies that permission to alter one element of the name is dependent on the permissions for the object (directory) in which that element of the name is contained. The confusion is boosted along by all those texts that explain the Unix tree-structured file system with a box at the top labelled "/" and lines to other boxes named "bin", "tmp", etc. This is wrong, of course: the names go on the lines ... Joe Yao jsdy@hadron.COM (not yet domainised) hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM} arinc,att,avatar,blkcat,cos,decuac,dtix,\ ecogong,empire,gong,grebyn,inco,insight, \!hadron!jsdy kcwc,lepton,netex,netxcom,phw5,rlgvax, / seismo,sms,smsdpg,sundc,uunet /
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/23/88)
In article <816@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes:
-The confusion is boosted along by all those texts that explain the
-Unix tree-structured file system with a box at the top labelled "/"
-and lines to other boxes named "bin", "tmp", etc. This is wrong, of
-course: the names go on the lines ...
100% right.
The UNIX file system design of inode data-objects (the "flat file
system") and multiple links to them (the "(sort of) hierarchical file
system", actually constrained to be a DAG (no relation)) is interesting
and useful, and deserves to be studied in its own right. An attempt to
establish a conceptual mapping between this scheme and another file
system implementation that has a different structure must at some
point be misleading.ok@quintus.uucp (Richard A. O'Keefe) (11/23/88)
In article <8956@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <480@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >->A utility such as "rm" COULD perform extra checks based on the permissions >-So does the System V Release 3.1 one, and, if I remember correctly, so >-did the V7 and perhaps even the V6 one; one can hardly flame Berkeley >-for this one. >But I think it was Berkeley who decided to prompt with a completely >misleading question! I've known others who disliked this. Hmm. Let's compare 4.2BSD and V.2 on a Sequent: % cp /dev/null zabbo % chmod 000 zabbo % att rm zabbo zabbo: 0 mode ? n % bsd rm zabbo rm: override protection 0 for zabbo? n What is "completely misleading" about that question? The file does in fact have mode/protection 0, and it is in fact rm which is asking me whether I want its reluctance to delete the file overridden. I always found the Sys V prompt rather obscure, especially when you run a script and the message pops up out of nowhere. At least the BSD prompt follows the convention of telling you which program is asking!
guy@auspex.UUCP (Guy Harris) (11/24/88)
>->A utility such as "rm" COULD perform extra checks based on the inode >->permissions. In fact the 4.nBSD "rm" does this ("override permissions >->on xxx?") and it is EXTREMELY annoying. >-So does the System V Release 3.1 one, and, if I remember correctly, so >-did the V7 and perhaps even the V6 one; one can hardly flame Berkeley >-for this one. > >But I think it was Berkeley who decided to prompt with a completely >misleading question! I've known others who disliked this. 1) That's beside the point; one can *still* hardly flame Berkeley for deciding to make "rm" "perform extra checks based on the inode permissions", which is what you were apparently complaining about. If you're going to bash Berkeley for the sheer fun of it, at least bash them for things that are their fault.... 2) Most other versions say "xxx: mmm mode ?" I don't see that this is any better or worse than "override permissions on xxx?" Neither one tells you precisely what the problem is. The Berkeley one is hardly "completely misleading"; the "rm" command prefers not to remove files with permissions that prevent the user from writing the file, and it's asking you whether you want to override that restriction.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/24/88)
In article <730@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >What is "completely misleading" about that question? "Override protection" implies that the link was protected against removal, which of course it wasn't. (If it HAD been, "rm" would have to change permissions on the directory before unlinking, which it doesn't.) I suppose the reason no "rm: " prefix was used was because in interactive use there isn't much question about where the prompt is coming from. (In a complex situation I agree there could be, so I wouldn't quarrel with adding "rm: " to the SVR2 prompt.) The real problem with these low-level UNIX utilities is that a lot of them attempt to "help", based on a simplistic model of their expected usage, whereas they should just do what they're told. "User friendliness" depends on the user; I generally find all these "confirm" prompts to get in the way. That sort of noise should be reserved for naive-user environments (Macintosh-style interfaces, for example), not wired into the basic tools. Of course I don't object to tools balking at patently incorrect usage, e.g. "cp a a" where "a" is an ordinary file. But I would be annoyed if "cp /dev/tty32 /dev/tty32" balked or asked me whether I really knew what I was doing. On reading the Ninth Edition UNIX manual some time ago, I was pleased to see that some of the worst quirks in the basic utilities had been cleaned up. For example, "cat" worked right without a -u option, unlike the System V version. UNIX is getting too fat these days. It would have been nice if every time an addition to the system had been proposed, first some other feature would have to have been identified for deletion from the system. That may have stalled some features until the right way to design them had been figured out. Now we're stuck with a hodge-podge of features that are poorly integrated, and paying customers who realy on the continued existence of those misfeatures. Sigh.
allbery@ncoast.UUCP (Brandon S. Allbery) (11/30/88)
As quoted from <730@quintus.UUCP> by ok@quintus.uucp (Richard A. O'Keefe): +--------------- | In article <8956@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: | >In article <480@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: | >->A utility such as "rm" COULD perform extra checks based on the permissions | >-So does the System V Release 3.1 one, and, if I remember correctly, so | >-did the V7 and perhaps even the V6 one; one can hardly flame Berkeley | >-for this one. | >But I think it was Berkeley who decided to prompt with a completely | >misleading question! I've known others who disliked this. | | Hmm. Let's compare 4.2BSD and V.2 on a Sequent: | % cp /dev/null zabbo | % chmod 000 zabbo | % att rm zabbo | zabbo: 0 mode ? n | % bsd rm zabbo | rm: override protection 0 for zabbo? n +--------------- If UUNET is any guide, V.2 on Sequents isn't. $ >foo $ chmod 0 foo $ rm foo rm: remove foo? n $ _ I've seen the above on quite a few systems of V.2, V.3, and Xenix 5.x pursuasions. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
ok@quintus.uucp (Richard A. O'Keefe) (11/30/88)
In article <13193@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >As quoted from <730@quintus.UUCP> by ok@quintus.uucp (Richard A. O'Keefe): >| % att rm zabbo >| zabbo: 0 mode ? n >| % bsd rm zabbo >| rm: override protection 0 for zabbo? n >If UUNET is any guide, V.2 on Sequents isn't. > $ >foo ; chmod 0 foo ; rm foo > rm: remove foo? n > >I've seen the above on quite a few systems of V.2, V.3, and Xenix 5.x >persuasions. UNIX System V/386 Release 3.0 80386 says foo: 0 mode ? just like the Sequent. There is more reason to doubt UUNET: the SVID clearly and explicitly states in RM(BU_CMD) that If a file has no write permission and the standard input is a terminal, its [presumably the file's] permissions are printed and a line is read from the standard input. Something which purports to be V.2 "rm" ought to obey the SVID and print the permissions *somehow* (though the SVID doesn't specify a format). Internationalisation will be a great opportunity to tidy this up.
rbj@nav.icst.nbs.gov (Root Boy Jim) (12/01/88)
? This is wrong, of course: the names go on the lines ...
Strictly speaking, yes. However, if you limit the discussion to
directorys only, and don't allow hard links to directorys (a practice
even I have resisted), then you can move the names into the (i)nodes.
? Joe Yao jsdy@hadron.COM (not yet domainised)
? hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM}
? arinc,att,avatar,blkcat,cos,decuac,dtix,\
? ecogong,empire,gong,grebyn,inco,insight, \!hadron!jsdy
? kcwc,lepton,netex,netxcom,phw5,rlgvax, /
? seismo,sms,smsdpg,sundc,uunet /
Somebody give this poor guy a domain :-)
(Root Boy) Jim Cottrell (301) 975-5688
<rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa>
Crackers and Worms -- Breakfast of Champions!guy@auspex.UUCP (Guy Harris) (12/01/88)
>There is more reason to doubt UUNET: Hell, I tried it a few hours ago on "uunet", and it worked the way Richard said it did on a Sequent. The "rm: remove foo?" prompt looks suspiciously like a "rm -i" prompt; perhaps on the systems where it was seen, "rm" was a script, shell function (or, if "ksh", alias) for "rm -i"? >Internationalisation will be a great opportunity to tidy this up. Yup, it'll get put into a file, probably; with any luck, users will be able to generate their own files, so you can get rm: overrideway rotectionpay 644 orfay /etc/passwd? On a more serious note, putting messages into files may have other advantages, such as 1) having people other than programmers write them (even if we write our native languages well, we may not know the best way to express what the message is trying to say) and 2) providing a nice database or databases listing all system messages, so you can consider listing them along with explanations for the perplexed, if the creator of the message in 1) can't make them self-explanatory.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/02/88)
In article <17672@adm.BRL.MIL> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: >? This is wrong, of course: the names go on the lines ... >Strictly speaking, yes. However, if you limit the discussion to >directorys only, and don't allow hard links to directorys (a practice >even I have resisted), then you can move the names into the (i)nodes. No, Joe was right and you're wrong. Consider (rootdir) / \ (subdirA) (subdirB) \ / (whatsit) By putting names on the inodes you have made it impossible to properly show that whatsit's name is different in the two subdirs containing it.
jsdy@uunet.uu.net (Joseph S. D. Yao) (12/03/88)
> ? This is wrong, of course: the names go on the lines ... > Strictly speaking, yes. However, if you limit the discussion to > directorys only, and don't allow hard links to directorys (a practice > even I have resisted), then you can move the names into the (i)nodes. [/] | --------------- /(bin) \(etc) [/] [/] \(telinit) /(init) --------------- | [ _____ ] Now, tell me, please, in this real-life situation (and I don't care whether you don't think System V is real life), which name should go in the little box in the bottom? Is it "init"? or "telinit"? (Sneaky me - neither fits, in this picture!) In the path names "/bin/telinit" and "/etc/init", the words "bin", "etc", "telinit", and "init" name path components. The nodes them- selves are reached by these path components, and the components are separated by "/", designating a node gone through. And it's not worth arguing a whole lot about, unless a false world- view somehow messes up your ability to correctly analyze a situation or write a proper program. Joe Yao (still @Hadron)
rbj@nav.icst.nbs.gov (Root Boy Jim) (12/09/88)
JSDY: This is wrong, of course: the names go on the lines ...
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
RBJ: Strictly speaking, yes. However, >IF YOU LIMIT THE DISCUSSION TO<
vvvvvvvvvvvvvvv ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RBJ: >DIRECTORYS ONLY<, and don't allow hard links to directorys (a practice
^^^^^^^^^^^^^^^
RBJ: even I have resisted), then you can move the names into the (i)nodes.
? From: "Joseph S. D. Yao" <hadron!jsdy@uunet.uu.net>
? [/]
? |
? ---------------
? /(bin) \(etc)
? [/] [/]
? \(telinit) /(init)
? ---------------
? |
? [ _____ ]
? Now, tell me, please, in this real-life situation (and I don't care
? whether you don't think System V is real life), which name should go
? in the little box in the bottom? Is it "init"? or "telinit"?
? (Sneaky me - neither fits, in this picture!)
? In the path names "/bin/telinit" and "/etc/init", the words "bin",
? "etc", "telinit", and "init" name path components. The nodes them-
? selves are reached by these path components, and the components are
? separated by "/", designating a node gone through.
? Joe Yao (still @Hadron)
Hey Joe, READ what I WROTE. I have highlighted what you missed. I understand
your point, and agree with you in the general case. You have violated my
(artificially imposed) conditions by adding files into the picture.
(Root Boy) Jim Cottrell (301) 975-5688
<rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa>
Crackers and Worms -- Breakfast of Champions!jsdy@uunet.uu.net (Joseph S. D. Yao) (12/19/88)
You're right, I did indeed miss that you were limiting the discussion to directory-only file systems. That is probably because I know that, however you try to disguise it, you're pretty bright; and I couldn't imagine that you'd be using a file system completely devoid of regular or special files - which strikes me as pretty useless. System administrators should be aware that you can make hard links to directories, although in most Unix-ische implementations this is considered "wrong" - except that all directories will have: one link from the parent directory; one link that is "."; and one link from each child directory that is "..". Joe Yao jsdy%hadron.UUCP@uunet.UU.NET tm - Unix is a trademark of AT&T Bell Labs.
rbj@nav.icst.nbs.gov (Nilbert T Bignum) (02/11/89)
? From: Doug Gwyn <gwyn@smoke.brl.mil>
? Date: 20 Nov 88 02:29:46 GMT
I'm a bit behind...
? The one extra wrinkle is that space used by an inode is reclaimed
? when it becomes totally inaccessible (last link to it is removed).
? All implementations of "symbolic links" that I know of are broken in
? this regard; even though symbolic links to an inode exist, the inode
? will vanish when all its "hard" links are removed (and the last open
? file table entry associated with it is closed).
I can think of places where this use might be desirable. Unfortunately,
`-llibname' doesn't look in `.', and the -L flag to ld is not universal.
A symlink in /usr/lib or /usr/local/lib to somewhere else is a way of
delegating authority to modify part of `the system' without giving
away any root privileges. Another example might be the X11 entrys in
/usr/{include,bin,lib}. And finally, some editors and other utilitys
rename the original file to the backup name and write a new version,
king hard links useless.
But you are lamenting the fact that symlinks are not ref counted.
If symlinks are `soft links', what you want is a `firm link' :-)
Firm links are symlinks that also bump the soft link ref count
field, which we also need to add to the inode. The kernel will
not reclaim an inode unless both ref counts are zero. An option
to unlink(2) can be added to decrement the soft count as well.
How about them feechurs!
Nilbert T Bignum <rbj@nav.icst.nbs.gov>
NTSI: Never Twice the Same Institute