On Thu, Oct 11, 2007 at 01:04:49PM -0500, Jonathan Wilson wrote: > On Wednesday 10 October 2007 13:04, Andrew Sackville-West wrote: > > On Tue, Oct 09, 2007 at 05:25:17PM -0700, tom arnall wrote: > > > Well, I got a list of perm's for stuff in /dev (from a sarge system. I'm > > > on etch). There were only two diff's: two sound devices. But there are > > > lots of insane permissions throughout the rest of the system. Is this > > > because when I did 'chmod -R 777 /dev' I also in effect did 'chmod -R 777 > > > /dev/hda1'? But when I do 'ls -R /dev/hda1' I get only '/dev/hda1'. Why > > > the diff' in the scope of the commands? And where do you read about this > > > kind of thing? > > > > well, ls and chmod are different utilities, so the -R could easily have > > different effects despite having apparently the same function. > > > > I seem to recall once I did a chown -R something and it followed the > > /. and /.. links in the directory so that it started walking up the > > directory tree. luckily I stopped it. Perhaps chmod -R is doing a > > similar thing? > > > > A > > That does /not/ happen with any utility's -R. They don't walk up the tree > with ../ , it would be way too dangerous to have any utility work that way.
Absolutely dangerous. So maybe I'll amend my statement above with an emphasis on the *seem* and *something*. The result was that I ended up chowning a bunch of stuff I didn't want to with ensuing chaos. My memory of the specifics are fuzzy. But it definitely ended up chowning up the tree *somehow*. > > The only way for a recursive run to get back up higher in the tree is > following a symlink (which is certainly a realistic possibility). this may have been the case. A
signature.asc
Description: Digital signature
