chown broken??
Hello I just hosed one of my boxes by recursively setting all my file permissions incorrectly: $ su $ cd /data $ chown -R andrew:wheel * $ chown -R andrew:wheel .* For some reason the last command was interpreted as: $ chown -R andrew:wheel /* I just cvsuped to 4.7 a few days ago, still running 4.7-RELEASE GENERIC kernel. Why does the behaviour of chown change when u r root? Surely this is a bug? And what the hell is this crap in the man page about -R: -R Change the user ID and/or the group ID for the file hierarchies rooted in the files instead of just the files themselves. As always, any assistance is appreciated! Cheers, -- Andrew Cutler [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
On Sat, Dec 21, 2002 at 12:22:32AM +1100, Andrew Cutler wrote: Hello I just hosed one of my boxes by recursively setting all my file permissions incorrectly: $ su $ cd /data $ chown -R andrew:wheel * $ chown -R andrew:wheel .* That matches ... Ceri -- My ancestors help the bold sons! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
Hi, On Sat, Dec 21, 2002 at 12:22:32AM +1100, Andrew Cutler wrote: I just hosed one of my boxes by recursively setting all my file permissions incorrectly: $ su $ cd /data $ chown -R andrew:wheel * This is all ok. $ chown -R andrew:wheel .* This isn't. For some reason the last command was interpreted as: $ chown -R andrew:wheel /* No, it was interpreted by your shell as: # chown -R andrew:wheel . .. .foo .bar other files starting with . Note the second entry, '..'. This translates to the directory above the one you are rooted in, as usual. In effect you recursively chown'ed every directory on your system, just as you asked. Why does the behaviour of chown change when u r root? It doesn't, only when you try this as a normal user you don't have the permissions to change ownership of /. Surely this is a bug? No, it isn't. And what the hell is this crap in the man page about -R: -R Change the user ID and/or the group ID for the file hierarchies rooted in the files instead of just the files themselves. It is another way of saying that chown will update ownership recursively, although I admit it is worded rather badly. HTH, --Stijn -- I really hate this damned machine I wish that they would sell it. It never does quite what I want But only what I tell it. msg12708/pgp0.pgp Description: PGP signature
Re: chown broken??
I realise that now, but why does chown not ignore the match since most other commands simply return? . is a directory -- ignored .. is a directory -- ignored This inconsistency is not logical. On Sat, 2002-12-21 at 00:26, Ceri Davies wrote: On Sat, Dec 21, 2002 at 12:22:32AM +1100, Andrew Cutler wrote: Hello I just hosed one of my boxes by recursively setting all my file permissions incorrectly: $ su $ cd /data $ chown -R andrew:wheel * $ chown -R andrew:wheel .* That matches ... Ceri -- Andrew Cutler [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
On Sat, Dec 21, 2002 at 12:36:36AM +1100, Andrew Cutler wrote: I realise that now, but why does chown not ignore the match since most other commands simply return? . is a directory -- ignored .. is a directory -- ignored This inconsistency is not logical. It is not inconsistent, the -R flag has told it to wend it's way through the directory hierarchy. And chown unadorned can change the ownerships of a directory as well. Maybe you want a flag that own recurses down the hierarchy and not up it ... ? Anyway the behaviour is consistent with other system commands that take a recursion flag (cp for example). Remember, sympathy is not abundant when mistakes are made as root .. since we have all been there .. :) or :( .. depending on your point of view. -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
Thus spake Andrew Cutler [EMAIL PROTECTED]: I realise that now, but why does chown not ignore the match since most other commands simply return? . is a directory -- ignored .. is a directory -- ignored This inconsistency is not logical. rm makes a special case for '.' and '..' specifically to avoid this kind of foot-shooting. It gets away with it because it doesn't make much sense to remove your current directory, much less its parent. Unfortunately, you can't really do the same thing for chown because people sometimes do say 'chown -R foo .' and really mean it. Since the '.*' is expanded by the shell, chown has no way of knowing what was really meant. (BTW, the example I gave shows you how to do what you were trying to do, without the problems you ran into.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
On 21 Dec 2002, Andrew Cutler wrote: I realise that now, but why does chown not ignore the match since most other commands simply return? . is a directory -- ignored .. is a directory -- ignored This inconsistency is not logical. It is not inconsistenct. chown can operate on directories. '.' and '..' are just like any other directory on the system. Fer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
# [EMAIL PROTECTED] / 2002-12-21 00:59:24 +1100: So without further embarrassment, does anyone have any idea on what is the quickest and easiest way to correct the file ownership issues that I'm currently experiencing ? restore from backup. if you don't backup, then reinstall. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
On Sat, Dec 21, 2002 at 12:59:24AM +1100, Andrew Cutler wrote: Thanks for everyone's quick responses. I'm not going to delve any deeper as to why chown, chmod etc match .. for .* when other commands do not. I'm sure this is ground that has been covered many times before. And I'm sure its the sort of mistake that you only make once. (In fact now that I think about it I'm sure there is a discussion of this issue in FreeBSD Unleashed/SAMS) And in starting this thread I feel like I've just committed some sort of UNIX newbie fopar. :) So without further embarrassment, does anyone have any idea on what is the quickest and easiest way to correct the file ownership issues that I'm currently experiencing ? mtree -U [insert other options here] Ceri -- May the ire of my ancestors bring your last day! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
- Original Message - From: Andrew Cutler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 20, 2002 2:22 PM Subject: chown broken?? Hello I just hosed one of my boxes by recursively setting all my file permissions incorrectly: $ su $ cd /data $ chown -R andrew:wheel * $ chown -R andrew:wheel .* For some reason the last command was interpreted as: $ chown -R andrew:wheel /* Nope; the recursion includes .. here: / in your case, as others already pointed out. I must say, though, that while I understand this behaviour, one can argue on what exactly recursive is to mean here. Intuitively, the definition of the current sub-directory and all sub-directories below the current directory (and that for each subdirectory) seems the correct one. Which would exclude .., as this is not a sub-directory of the current directory, but the parent. But this behavior is not inconsistent; try cp -R .*, and you will find it does the same. :) - Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
On Fri, Dec 20, 2002 at 03:12:17PM +0100, Mark wrote: I must say, though, that while I understand this behaviour, one can argue on what exactly recursive is to mean here. Intuitively, the definition of the current sub-directory and all sub-directories below the current directory (and that for each subdirectory) seems the correct one. Which would exclude .., as this is not a sub-directory of the current directory, but the parent. Not really. It recurses through the directories named on the command line, of which '..' happens to be one. Ceri -- By Moradin, I shall avenge the devastation of my beards! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
- Original Message - From: Ceri Davies [EMAIL PROTECTED] To: Mark [EMAIL PROTECTED] Cc: Andrew Cutler [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, December 20, 2002 3:15 PM Subject: Re: chown broken?? On Fri, Dec 20, 2002 at 03:12:17PM +0100, Mark wrote: I must say, though, that while I understand this behaviour, one can argue on what exactly recursive is to mean here. Intuitively, the definition of the current sub-directory and all sub-directories below the current directory (and that for each subdirectory) seems the correct one. Which would exclude .., as this is not a sub-directory of the current directory, but the parent. Not really. It recurses through the directories named on the command line, of which '..' happens to be one. Yes, the directories named on the command line within the CURRENT directory. Technically, . and .. are entries within the current directory (try: od -c .), and they have inode numbers too. But that does not deter me from deeming it a bit counter-intuitive to consider .. a directory of the current directory. :) Especially in the context of recursion. - Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
On Fri, Dec 20, 2002 at 03:48:41PM +0100, Mark wrote: On Fri, Dec 20, 2002 at 03:12:17PM +0100, Mark wrote: I must say, though, that while I understand this behaviour, one can argue on what exactly recursive is to mean here. Intuitively, the definition of the current sub-directory and all sub-directories below the current directory (and that for each subdirectory) seems the correct one. Which would exclude .., as this is not a sub-directory of the current directory, but the parent. Not really. It recurses through the directories named on the command line, of which '..' happens to be one. Yes, the directories named on the command line within the CURRENT directory. Technically, . and .. are entries within the current directory (try: od -c .), and they have inode numbers too. But that does not deter me from deeming it a bit counter-intuitive to consider .. a directory of the current directory. :) Especially in the context of recursion. You're saying that chown -R 700 /tmp doesn't work then ? Ceri -- Face the fire of a 250 pound woman! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
please don't cc me, I'll pick up your reply from the list. # [EMAIL PROTECTED] / 2002-12-20 12:39:31 -0300: On Fri, 20 Dec 2002, Roman Neuhauser wrote: apart from what others said about wildcard substitution: roman@freepuppy /usr 1005:1 ls -l .* zsh: no matches found: .* roman@freepuppy /usr 1006:1 zsh (at least with my settings) would protect you from yourself in this situation. And will prevent you from doing it when you really need it :) any problem with this? cd .. chmod -R . zsh's behavior actually allows you to chmod only dotfils/dotdirs: roman@freepuppy ~/tmp 1013:0 echo .* .htaccess .mail .vim roman@freepuppy ~/tmp 1014:0 -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
On Fri, 20 Dec 2002, Roman Neuhauser wrote: any problem with this? cd .. chmod -R . zsh's behavior actually allows you to chmod only dotfils/dotdirs: roman@freepuppy ~/tmp 1013:0 echo .* .htaccess .mail .vim roman@freepuppy ~/tmp 1014:0 Because zsh's * never matches a dot at the begining. I am used to sh's semantics, I know what * expands to, and proceed acording to that. Fer -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
on 12/20/02 7:39 AM, Fernando Gleiser [EMAIL PROTECTED] wrote: On Fri, 20 Dec 2002, Roman Neuhauser wrote: apart from what others said about wildcard substitution: roman@freepuppy /usr 1005:1 ls -l .* zsh: no matches found: .* roman@freepuppy /usr 1006:1 IOW, the behavior is actually shell- (and shell configuration-) dependent. Yes, because wildcard expansion is done by the shell. zsh (at least with my settings) would protect you from yourself in this situation. And will prevent you from doing it when you really need it :) I don't know zsh, but if it has a setting that prevents wildcard expansion from including .. as a match for .* that strikes me as an all-around good thing. When do you _really_need_ .* to match .. ? You could in such a situation type .. explicitly, just as you would often add .* when * does not work. One possible approach with some nice consistency would be: * matches:foo but not .foo .* matches:.foobut not ..foo (and not ..) Of course to remain fully consistent with this approach (by one interpretation), foo* would not match foo.foo - rather you would have to type foo.* or foo*.* according to your needs. This might fail to meet expectatons in more situations than the ones it fixes. That aside, even an interpretation of .* that allows ..fo but simply disallows only .. still strikes me as an all-around good thing. Anyone hurt by this (at least on the command line) can simply add .. explicitly to the list. Maybe it would be an improvement to unix if this change were made to all shells, or even just to go into prompt for y mode when hitting .. in this one case (if the shell is interactive). Kurt Bigler Fer -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
In the last episode (Dec 20), Giorgos Keramidas said: On 2002-12-20 14:00, Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Dec 20), Kurt Bigler said: I don't know zsh, but if it has a setting that prevents wildcard expansion from including .. as a match for .* that strikes me as an all-around good thing. zsh's rules are that no filename generation pattern ever matches the files `.' or `..'. There is also a GLOB_DOTS option that when set makes * match files starting with a dot as well. You can enable GLOB_DOTS for a single pattern by using a glob qualifier: *(D) That's no good either. How does someone `chmod 700 .' with zsh then? `chmod 700 .', of course :) The rule only applies to wildcards (i.e. filename generation patterns). -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
- Original Message - From: Gary W. Swearingen [EMAIL PROTECTED] To: Mark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, December 20, 2002 10:28 PM Subject: Re: chown broken?? Mark [EMAIL PROTECTED] writes: Yes, the directories named on the command line within the CURRENT directory. Technically, . and .. are entries within the current directory (try: od -c .), and they have inode numbers too. But that does not deter me from deeming it a bit counter- intuitive to consider .. a directory of the current directory. :) Especially in the context of recursion. The manpage explicitly mentions neither directories or recursion, Indeed; and I was going to mention this too, as the man page seems to have gone out of its way to avoid the word recursion and directrory. -R Change the user ID and/or the group ID for the file hierarchies rooted in the files instead of just the files themselves. Then I looked at the man page for cp -R .*, which acts like chown -R .*, and read: -R If source_file designates a directory, cp copies the directory and the entire subtree connected at that point. Now, see, this is legible to me. :) - Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: chown broken??
On Fri, Dec 20, 2002 at 07:49:27PM -0800, David Schultz wrote: Thus spake Mark [EMAIL PROTECTED]: - Original Message - From: Ceri Davies [EMAIL PROTECTED] To: Mark [EMAIL PROTECTED] Cc: Andrew Cutler [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, December 20, 2002 3:15 PM Subject: Re: chown broken?? On Fri, Dec 20, 2002 at 03:12:17PM +0100, Mark wrote: I must say, though, that while I understand this behaviour, one can argue on what exactly recursive is to mean here. Intuitively, the definition of the current sub-directory and all sub-directories below the current directory (and that for each subdirectory) seems the correct one. Which would exclude .., as this is not a sub-directory of the current directory, but the parent. Not really. It recurses through the directories named on the command line, of which '..' happens to be one. Yes, the directories named on the command line within the CURRENT directory. Technically, . and .. are entries within the current directory (try: od -c .), and they have inode numbers too. But that does not deter me from deeming it a bit counter-intuitive to consider .. a directory of the current directory. :) Especially in the context of recursion. So you want 'chown foo ..' to fail, as a special case? As I mentioned before, rm gets away with this because you don't want to remove the parent of the directory you're currently in. (Actually, some rm implementations *will* let you shoot yourself in the foot.) But it's perfectly reasonable to chown '..', even recursively, so chown can't make any assumptions. I object to going around and documenting this caveat in the manpages for every single utility that supports recursion through a directory tree. It doesn't really belong there, it belongs in a ``How to use the shell'' tutorial. The way Unix traditionally does parameter expansion makes it easy to shoot yourself in the foot in at least a dozen ways, and this is just one of them. There is a little comfort-factor trick for all of this, that I use a lot on those paranoid days, execute the command first with an echo in front of it, then you will see what is going to happen..for example: [admin@willow]:~$ echo chown cls:cls .* chown cls:cls . .. .bash_history .bashrc .cshrc .forward .login .login_conf .mail_aliases .mailcap .mailrc .muttrc .procmailrc .profile .rhosts .shrc .signature .ssh [admin@willow]:~$ Of course this may not be 100% the truth if the program you are echoing makes a special case of . etc. But it does show you what the shell will expand your command line to. -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
