[ILUG] repair permissions
blf at blf.utvinternet.co.uk
Fri Mar 18 20:04:41 GMT 2005
| From: Niall O Broin <niall at linux.ie>
| Date: Fri, 18 Mar 2005 00:13:17 +0000
| On 17 Mar 2005, at 20:03, Brian Foster wrote:
| > my answer is the classic paper by Rob Pike and Brian W Kernighan,
| > “Cat -V Considered Harmful”, http://netlib.bell-labs.com/cm/cs/doc/
| Of similar quality to most of these gentlmen's published writings,
| I don't think it's particularly relevant here.
then we disagree. the problem, as I see it, is an un-necessary
functionality (and option) was added to chown(1), chmod(1), and
chgrp(1) — recursively descending a directory hierarchy — and it
does not even work! try (as a normal user, not the superuser):
chmod -R 0 A
with GNU `chmod', the following happens:
• the mode of A/ is changed to the requested 000 (Ok).
• the error “chmod: `A': Permission denied” is issued (bad).
• the mode of A/F is not changed (bad).
that example may be slightly artifical, but alter the mode
to be 400 (or 440 or 444) instead of 0, and you have a very
plausible scenario: the user clearly wants all the _files_
to be readonly. a trivial task using find(1). but impossible
with `chmod -R': the mode is not only applied to files _and_
directories (mistake 1) but also top-down (mistake 2).†
so what is the fix? add yet more of `find's capabilities
into `chmod'? (in this case, probably `-depth' and `-type'.)
this sort of thing is just what Pike et.al. were complaining
about — a poorly thought-out case of featuritis begating yet
more problems, “features”, and a thicker manual. yet without
improving the overall generality/power of the system in any
| > in case it is not clear, I maintain `chmod -R' is a badly designed
| > tool, arguably produced by “haphazard hacking”, and `find' is the
| > power tool.
| It was clear enough. I happen to disagree. Would you also remove the -r
| option from rm & chown ? [ ... ]
NO. now, today, some c.20(!) years after the deed, I would
not remove `-R' from the 3 `ch...'s (nor `r' from `rm', but
that is a different case anyways).‡ but I might consider
*speculating* (I was not at UCB at the time and do not know
the rationale for the decision — which is why, in my first
post, I asked why BSD added `-R'), I would have _not_added_
`-R' to `chmod', `chown', and `chgrp' in the first place.
( nor `-v' to cat(1), or the columniation to ls(1) ;-)
esp. as the system I was using at that time had the
general-purpose tools mc(1) and vis(1) Pike et.al.
mentioned in the paper. )
incidently, how does `cat -v' play with UTF-8? ;-)
† you only need to change the directory mode after
the mode of all contained files and (recursively)
subdirectories have been changed, which perhaps is
not strictly “bottom-up”, but close enough...
‡ it would not be a good idea to remove `-r' from `rm' for
completely different reasons. here is a hint as to why:
`rm' changes the contents of directories. combine with
`find' and .... oops!: could be made to work, but a
hierarchy-altering operation does not play well with a
concurrent hierarchy-scanning operation.
Experienced (20+ yrs) kernel/software Eng: | Brian Foster Montpellier,
• Unix, embedded, &tc; • Linux; • doc; | blf at utvinternet.ie FRANCE
• IDL, automated testing, process, &tc. | Stop E$$o (ExxonMobile)!
Résumé (CV) http://www.blf.utvinternet.ie | http://www.stopesso.com
More information about the ILUG