Re: NO! chmod strikes!
On Mon, Jul 16, 2001 at 02:01:53PM -0400, Alan Shutko wrote: > > > So, does anyone have a way to recover using only shell builtins, for > > just in case there aren't any executable files left? > The sash shell (in the sash package) has built-ins for most of these utilities (chmod, chown, ls, cp, mv and rm included). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: NO! chmod strikes!
Dave Sherohman <[EMAIL PROTECTED]> writes: > Easy enough to bootstrap yourself out of that one, provided /bin/cp > is still executable: Or, if /lib/ld-linux.so.2 is still executable: /lib/ld-linux.so /bin/chmod a+x /bin/chmod > So, does anyone have a way to recover using only shell builtins, for > just in case there aren't any executable files left? Not that I can think of -- Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors! I have not yet begun to byte!
Re: [users] NO! chmod strikes!
On Sun, Jul 15, 2001 at 12:41:34PM +0200, Joost Kooij wrote: > Thanks for the compliment. Don't ruin your system just to try this, > because it is not perfect. Consider what happens if you: > > chmod a-x /bin/chmod Easy enough to bootstrap yourself out of that one, provided /bin/cp is still executable: # umask 000 # cp /bin/cp /tmp/new-chmod # cat /bin/chmod > /tmp/new-chmod # /tmp/new-chmod a+x /bin/chmod The trick is that, although cp won't add execute permissions to the copied file, it will preserve them by default. (umask permitting, of course.) So, does anyone have a way to recover using only shell builtins, for just in case there aren't any executable files left? (I don't think it can be done, but it would be great to be proven wrong...)
Re: [users] NO! chmod strikes!
On Sat, Jul 14, 2001 at 10:21:51AM -0400, [EMAIL PROTECTED] wrote: > Joost, your solution was such an elegant thing, that to > ruin my system to learn it was fair enough. Thanks for the compliment. Don't ruin your system just to try this, because it is not perfect. Consider what happens if you: chmod a-x /bin/chmod > > but anyway, a question for all debianers: how do you get the default > > permissions back on the / tree? > > If you have a clean host with very similar filesystem contents, try this: > > ssh [EMAIL PROTECTED] "find / -regex '/\(mnt\|proc\|tmp\)/.*' -prune -or \ > -not -type l -not -type s -printf '%04.4m %u %g %p\n' " \ > | while read mode user group path > do > chown $user.$group $path > chmod $mode $path > done Cheers, Joost
Re: [users] NO! chmod strikes!
Joost, your solution was such an elegant thing, that to ruin my system to learn it was fair enough. Thank you. --Original Message-- by joost On Mon, Jul 09, 2001 at 06:36:08PM +0200, Martin F. Krafft wrote: > but anyway, a question for all debianers: how do you get the default > permissions back on the / tree? If you have a clean host with very similar filesystem contents, try this: ssh [EMAIL PROTECTED] "find / -regex '/\(mnt\|proc\|tmp\)/.*' -prune -or \ -not -type l -not -type s -printf '%04.4m %u %g %p\n' " \ | while read mode user group path do chown $user.$group $path chmod $mode $path done Alternatively, create a huge script like this: find / -regex '/\(mnt\|proc\|tmp\)/.*' -prune -or \ -not -type l -not -type s -printf 'chown %u.%g %p\nchmod %m %p\n' \ > fixperms.sh And copy that to the broken machine and run "sh fixperms". It might not fix all files, unless the two hosts are nearly equal, but enough to let you find the missing ones to fix by hand. Maybe /home/* will need special care. Cheers, Joost
Re: NO! chmod strikes!
%% Dave Sherohman <[EMAIL PROTECTED]> writes: ds> Changing it to: ds> find . -name .[^.] -print0 | xargs -0 chmod r-owx Not to be anal retentive, but ITYM: ... -name '.[^.]*' ... Your glob won't match anything except ".x" where x is exactly one character long but != ".". -- --- Paul D. Smith <[EMAIL PROTECTED]>HASMAT--HA Software Methods & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Re: NO! chmod strikes!
On Tue, Jul 10, 2001 at 10:42:42PM -0400, Paul D. Smith wrote: > %% Dave Sherohman <[EMAIL PROTECTED]> writes: > ds> On Mon, Jul 09, 2001 at 12:29:40PM -0400, Paul D. Smith wrote: > dc> find . -print0 | xargs -0 chmod r-owx > ds> while the find version will leave .foo/bar alone and change > ds> foo/.bar (it looks at each filename independently). > > Not true at all; the find version will change _both_ .foo/bar _and_ > foo/.bar. > > "find ." matches everything in the current directory and below, > _including_ hidden files. I stand corrected. As written, the find command will change the permissions on everything within the current directory, regardless of name. I wasn't paying attention and didn't notice that dc forgot to include a filter on the filenames. Changing it to: find . -name .[^.] -print0 | xargs -0 chmod r-owx would cause it to change foo/.bar but not .foo/bar (although .foo/ itself would be changed unless another clause were added to filter out directories). As for the OP's intent, it must not have been clear, as you think he wanted to change the perms on all hidden objects (including the contents of hidden directories) within the current directory and I (based on the -R in his original chmod) believe that he wanted to change all hidden objects (excluding non-hidden files within hidden directories) within the current directory or its children.
Re: [users] NO! chmod strikes!
On Tue, Jul 10, 2001 at 01:12:37AM +0200, Joost Kooij wrote: > On Mon, Jul 09, 2001 at 06:36:08PM +0200, Martin F. Krafft wrote: > > but anyway, a question for all debianers: how do you get the default > > permissions back on the / tree? > > If you have a clean host with very similar filesystem contents, try this: > > ssh [EMAIL PROTECTED] "find / -regex '/\(mnt\|proc\|tmp\)/.*' -prune -or \ > -not -type l -not -type s -printf '%04.4m %u %g %p\n' " \ > | while read mode user group path > do > chown $user.$group $path > chmod $mode $path > done DANG. nice implementation there! > Alternatively, create a huge script like this: > > find / -regex '/\(mnt\|proc\|tmp\)/.*' -prune -or \ > -not -type l -not -type s -printf 'chown %u.%g %p\nchmod %m %p\n' \ > > fixperms.sh > > And copy that to the broken machine and run "sh fixperms". > > It might not fix all files, unless the two hosts are nearly equal, but > enough to let you find the missing ones to fix by hand. Maybe /home/* > will need special care. not too shabby here, either. but i really like that first one. how about coming up with some more clever script examples? a thousand debianistas are waiting to adore (and newbies are waiting to learn)... newbieDoc.sourceForge.net could use your brain... c'mon, just a few more shell scripts. awesome! -- DEBIAN NEWBIE TIP #48 from Will Trillich <[EMAIL PROTECTED]> : To peruse your CURRENT VIM SETTINGS (there's LOTS of them) from within Vim, simply do :options You can change them there, on-the-fly, as well. Type "ctrl-W ctrl-W" to switch "panes" or "ctrl-W q" to close one. Try ":help" to learn more. Also see http://newbieDoc.sourceForge.net/ ...
Re: NO! chmod strikes!
On Sun, Jul 08, 2001 at 10:14:12PM -0400, Paul D. Smith wrote: > Both chmod -R and ls -R behave the same way. However, your description > above is not actually what happens, and I haven't seen anyone else here > correct it in so many words. So, just to be clear: > > Remember that the shell expands all wildcards, not the application. So, > supposing you had these files/directories in your current working > directory: > > . .. .foo .bar .biz baz boz > > Then, the command "chmod -R o-rwx .*" is identical (from the point of > view of chmod, which only gets the postprocessed commandline) to having > typed this: > > chmod -R o-rwx . .. .foo .bar .biz > > > _Neither_ ls nor chmod (nor any other tool that recurses that I've ever > heard of) will follow ".." in a directory as it's recursing. > > However, if you give ".." on the command line, of course it will operate > on that directory just like it would any other directory on the command > line. > > The upshot is, "chmod -R o-rwx .." will change the permissions in the > parent directory and all of its subdirectories, recursively; it will > start from the directory above the current directory and walk down. > > It will _NOT_ walk back _up_ the tree any further up from the parent. > > Ditto for "find", "ls", "diff -r", etc. etc. > > So, the what happened here depends on your working directory. If you > ran the command in /root (or any other directory which is an immediate > subdirectory of /), then the chmod started at / and your entire system > got chmod'd and your system is relatively screwed. > > If you ran it from a deeper directory, say /root/foo, then only the files > under /root were changed; that may be less terminal. beware "One True Way". hmph: > BTW, the best way to do what you wanted to do is this: > > $ chmod -R o-owx .[!.]* > > That will change everything, recursively, beginning with a ".", except > "." and "..". Modern shells also accept the more standard RE format: > > $ chmod -R o-owx .[^.]* hey. nice job. lucid, wide coverage, reasonable depth. how 'bout wrapping that up into a newbiedoc on GLOBs and PATHs? http://newbieDoc.sourceForge.net/ hmm? -- DEBIAN NEWBIE TIP #57 from Steve Kowalik <[EMAIL PROTECTED]> : Wondering HOW TO SET YOUR TIME ZONE? Your system clock may be showing UTC or GMT but you want it to display PDT or whatever. Just run "tzconfig" as root. (You're sure to have it on your debian system already -- it's provided in package "libc6".) Also see http://newbieDoc.sourceForge.net/ ...
Re: NO! chmod strikes!
%% Dave Sherohman <[EMAIL PROTECTED]> writes: ds> On Mon, Jul 09, 2001 at 12:29:40PM -0400, Paul D. Smith wrote: >> >> BTW, the best way to do what you wanted to do is this: >> >> >> >> $ chmod -R o-owx .[!.]* dc> Or even better, ignore the -R in the chmod command and use find: dc> find . -print0 | xargs -0 chmod r-owx >> Not to be argumentative, but what's better about it? ds> While I won't presume to judge which is better, there is a difference: Certainly there's a difference; my second sentence was: > First, your example doesn't do what the OP wanted to do, or what my > example does do. ds> The chmod -R version will affect .foo/bar and ignore foo/.bar (it ds> looks only at names in the directory where the command is issued) Yes, that was exactly the point of my second paragraph. ds> while the find version will leave .foo/bar alone and change ds> foo/.bar (it looks at each filename independently). Not true at all; the find version will change _both_ .foo/bar _and_ foo/.bar. "find ." matches everything in the current directory and below, _including_ hidden files. -- --- Paul D. Smith <[EMAIL PROTECTED]>HASMAT--HA Software Methods & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Re: NO! chmod strikes!
On Mon, Jul 09, 2001 at 12:29:40PM -0400, Paul D. Smith wrote: > %% Dave Carrigan <[EMAIL PROTECTED]> writes: > >> BTW, the best way to do what you wanted to do is this: > >> > >> $ chmod -R o-owx .[!.]* > > dc> Or even better, ignore the -R in the chmod command and use find: > > dc> find . -print0 | xargs -0 chmod r-owx > > Not to be argumentative, but what's better about it? While I won't presume to judge which is better, there is a difference: The chmod -R version will affect .foo/bar and ignore foo/.bar (it looks only at names in the directory where the command is issued) while the find version will leave .foo/bar alone and change foo/.bar (it looks at each filename independently).
Re: [users] NO! chmod strikes!
On Mon, Jul 09, 2001 at 06:36:08PM +0200, Martin F. Krafft wrote: > but anyway, a question for all debianers: how do you get the default > permissions back on the / tree? If you have a clean host with very similar filesystem contents, try this: ssh [EMAIL PROTECTED] "find / -regex '/\(mnt\|proc\|tmp\)/.*' -prune -or \ -not -type l -not -type s -printf '%04.4m %u %g %p\n' " \ | while read mode user group path do chown $user.$group $path chmod $mode $path done Alternatively, create a huge script like this: find / -regex '/\(mnt\|proc\|tmp\)/.*' -prune -or \ -not -type l -not -type s -printf 'chown %u.%g %p\nchmod %m %p\n' \ > fixperms.sh And copy that to the broken machine and run "sh fixperms". It might not fix all files, unless the two hosts are nearly equal, but enough to let you find the missing ones to fix by hand. Maybe /home/* will need special care. Cheers, Joost
Re: [users] NO! chmod strikes!
also sprach [EMAIL PROTECTED] (on Sun, 08 Jul 2001 04:17:34PM -0400): > I tried, in a subdir of /root, the command > chmod -R o-rwx .* > It changed the permissions on the parent directory, > the parent's parent directory, all the way up. > > Now only root can use my computer. > > Was chmod supposed to understand .* so differently > than /bin/ls does? yes. you said recursively, and '..', which is a match for .* is a virtual subdirectory of any directory. with chmod, if you want to recursively change a directory's permissions, either do chmod -R directory from the parent, or chmod -R . in the directory. but anyway, a question for all debianers: how do you get the default permissions back on the / tree? martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] -- oxymoron: micro$oft works pgpSRBQMOnQOt.pgp Description: PGP signature
Re: NO! chmod strikes!
%% Dave Carrigan <[EMAIL PROTECTED]> writes: dc> "Paul D. Smith" <[EMAIL PROTECTED]> writes: >> BTW, the best way to do what you wanted to do is this: >> >> $ chmod -R o-owx .[!.]* dc> Or even better, ignore the -R in the chmod command and use find: dc> find . -print0 | xargs -0 chmod r-owx Not to be argumentative, but what's better about it? First, your example doesn't do what the OP wanted to do, or what my example does do. In order to do that you _still_ have to use my globbing expression (or else use some truly bizarre contortion in find--see other posters to this thread as they try to come up with one): find .[!.]* -print0 | xargs -0 chmod r-owx Second, your example has a lot more typing in it, and although anyone doing UNIX sysadmin needs to be familiar with this pattern, it's definitely more complex than -R. You _could_ have argued that the -R flag is not standard, and so the -R version won't work everywhere... but the -R is a lot more portable and works on a lot more versions of UNIX than the find -print0/xargs -0 flags, which _only_ work with GNU find and xargs. So... I'm not seeing it :). -- --- Paul D. Smith <[EMAIL PROTECTED]>HASMAT--HA Software Methods & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Re: NO! chmod strikes!
"Paul D. Smith" <[EMAIL PROTECTED]> writes: > BTW, the best way to do what you wanted to do is this: > > $ chmod -R o-owx .[!.]* Or even better, ignore the -R in the chmod command and use find: find . -print0 | xargs -0 chmod r-owx -- Dave Carrigan ([EMAIL PROTECTED])| YOW!! Everybody out of the UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-DNS | GENETIC POOL! Seattle, WA, USA| http://www.rudedog.org/ |
Re: NO! chmod strikes! -- oops
hiya marin
> > if you only wanted to change the local dot files... oh well...
> > we all learn and remember the hard way... :-)
> > shoulda been: chmod pattern ~/.*
>
> NO. ~/.* includes .. ~/.. too, if expanded by the shell. In this case this
> would be /root/.. which is nothing els but / ... the same mess again :-)
yes...
there's few ways to do it...
problem with that find below is it pick up .elm, .ssh, .netscape
directories too
so the find has to be told files only ( -type f )
which means the "-not" options should not be needed
find ~ -name ".*" -type f -exec ls -la {}\; -or-
find ~ -name ".*" -type f -ls
if that works... ( picks out what you want ... ) than...
find ~ -name ".*" -type f -exec chmod pattern {}\;
might(will) be easier to explicitly specify the list of files you
want directly to chmod since you could have dozens of various dot files
and dot dirs
have fun
alvin
>find -name ".*" -not -name ".." -not -name "." -maxdepth 1
>
> is one way to get all dot-files and dot dirs in the same dir, this piped
> through a
>
>xargs chmod -R o-rwx
>
> will do what the "chmod -R o-rwx .*" was supposed to do in the original
> post...
>
> Martin
>
Re: NO! chmod strikes!
> if you only wanted to change the local dot files... oh well... > we all learn and remember the hard way... :-) > shoulda been: chmod pattern ~/.* NO. ~/.* includes .. ~/.. too, if expanded by the shell. In this case this would be /root/.. which is nothing els but / ... the same mess again :-) find -name ".*" -not -name ".." -not -name "." -maxdepth 1 is one way to get all dot-files and dot dirs in the same dir, this piped through a xargs chmod -R o-rwx will do what the "chmod -R o-rwx .*" was supposed to do in the original post... Martin
Re: NO! chmod strikes!
Thanks for the very full explanation. Sigh. Reinstall? I have done fresh installs many times. Sorry I don't know the drill for reinstalls. I could move the stuff I want to save to one parti tion, and then reinstall on just / and /boot? Josh Narins PS Tough to type like that :)
Re: NO! chmod strikes! -- ooopss
On 8 Jul 2001, David Z Maze wrote: > Alvin Oga <[EMAIL PROTECTED]> writes: > AO> if you only wanted to change the local dot files... oh well... > AO> we all learn and remember the hard way... :-) > AO> shoulda been: chmod pattern ~/.* > > ...which will still catch ~/. and ~/.., which you don't want. yeah... oooppss was just merrily typing ... sorry for the boo-boo .. hope nobody ran that command chmod pattern .[a-z]* .bashrc, .bash_history, .bash_profile, .login, .profile, .rhosts, etc... but than again...that will change the .elm, .netscape too so you'd need more twiddling and if ya make a mistake or afraid to run a command... backup the stuff first...than try it... or read up first.. if it gets brokentake advantage of it..and try to fix it... learning new ways to break things and fix things is sometimes fun ?? have fun linuxing alvin > (Particularly as root, whose home directory is conventionally /root; > /root/.. is the system root directory, which gets you back into the > same mess that you started as.) > > A good reminder: if you're not sure about what you're doing, it's a > good idea to (a) not run them as a priviledged user (root) without > checking first, and (b) check commands you're not sure of by putting > 'echo' on the front first to see what the shell will turn them into. > > -- > David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ > "Theoretical politics is interesting. Politicking should be illegal." > -- Abra Mitchell > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: NO! chmod strikes!
%% [EMAIL PROTECTED] writes: j> 1. ( ) text/plain (*) text/html No need for HTML on the mailing list. j> I tried, in a subdir of /root, the command j> chmod -R o-rwx .* j> It changed the permissions on the parent directory, j> the parent's parent directory, all the way up. j> Now only root can use my computer. j> Was chmod supposed to understand .* so differently j> than /bin/ls does? Both chmod -R and ls -R behave the same way. However, your description above is not actually what happens, and I haven't seen anyone else here correct it in so many words. So, just to be clear: Remember that the shell expands all wildcards, not the application. So, supposing you had these files/directories in your current working directory: . .. .foo .bar .biz baz boz Then, the command "chmod -R o-rwx .*" is identical (from the point of view of chmod, which only gets the postprocessed commandline) to having typed this: chmod -R o-rwx . .. .foo .bar .biz _Neither_ ls nor chmod (nor any other tool that recurses that I've ever heard of) will follow ".." in a directory as it's recursing. However, if you give ".." on the command line, of course it will operate on that directory just like it would any other directory on the command line. The upshot is, "chmod -R o-rwx .." will change the permissions in the parent directory and all of its subdirectories, recursively; it will start from the directory above the current directory and walk down. It will _NOT_ walk back _up_ the tree any further up from the parent. Ditto for "find", "ls", "diff -r", etc. etc. So, the what happened here depends on your working directory. If you ran the command in /root (or any other directory which is an immediate subdirectory of /), then the chmod started at / and your entire system got chmod'd and your system is relatively screwed. If you ran it from a deeper directory, say /root/foo, then only the files under /root were changed; that may be less terminal. BTW, the best way to do what you wanted to do is this: $ chmod -R o-owx .[!.]* That will change everything, recursively, beginning with a ".", except "." and "..". Modern shells also accept the more standard RE format: $ chmod -R o-owx .[^.]* -- --- Paul D. Smith <[EMAIL PROTECTED]>HASMAT--HA Software Methods & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Re: NO! chmod strikes!
Alvin Oga <[EMAIL PROTECTED]> writes: AO> if you only wanted to change the local dot files... oh well... AO> we all learn and remember the hard way... :-) AO> shoulda been: chmod pattern ~/.* ...which will still catch ~/. and ~/.., which you don't want. (Particularly as root, whose home directory is conventionally /root; /root/.. is the system root directory, which gets you back into the same mess that you started as.) A good reminder: if you're not sure about what you're doing, it's a good idea to (a) not run them as a priviledged user (root) without checking first, and (b) check commands you're not sure of by putting 'echo' on the front first to see what the shell will turn them into. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: NO! chmod strikes!
hi ya josh
the .* told it to change it to the directory above it too...
geez what fun
if you only wanted to change the local dot files... oh well...
we all learn and remember the hard way... :-)
shoulda been: chmod pattern ~/.*
an easy fix might be:
( your system might/is hosed anyway..might as well play
( around a bit and experiment -- see if you can undo the damage
cd /root
find . -type d -exec chmod 775 {} \;
find . -typAe f -exec chmod 644 {} \;
and change to the other dirs ( / and all dirs at / )
and do the same..
if you did other commands too that'd be harder to fix
c ya
alvin
On Sun, 8 Jul 2001, Alan Shutko wrote:
> [EMAIL PROTECTED] writes:
>
> > Is there any chance chmod -R o-rwx .* started working
> > on subdirectories of / ?
>
> Yes, since that's what -R means. Your system is hosed. Reinstall.
>
Re: NO! chmod strikes!
[EMAIL PROTECTED] writes: > Is there any chance chmod -R o-rwx .* started working > on subdirectories of / ? Yes, since that's what -R means. Your system is hosed. Reinstall. -- Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors! Do not think by infection, catching an opinion like a cold.
Re: NO! chmod strikes!
On Sun, Jul 08, 2001 at 06:25:27PM -0400, [EMAIL PROTECTED] wrote: > > Ah, I see now how -R and .* could get kinda crazy. > > Thank you. > > But I changed the perms of / a bit, but it still won't > work (cd is now working for regular user, but no logins, > nor does ls work). /bin/login is setuid. I think it bails out if it's permissions are wrong (a security feature). > Does anyone have a proper perms setup for / ? > Is there any chance chmod -R o-rwx .* started working > on subdirectories of / ? Your safest bet is probably to reinstall. Otherwise, you'll have a terrible time trying to plug all the security holes you've probably created. -- Eric G. Miller
Re: NO! chmod strikes!
Ah, I see now how -R and .* could get kinda crazy.
Thank you.
But I changed the perms of / a bit, but it still won't
work (cd is now working for regular user, but no logins,
nor does ls work).
Does anyone have a proper perms setup for / ?
Is there any chance chmod -R o-rwx .* started working
on subdirectories of / ?
Thanks :)
-josh narins
---Message Replied To Below--
On Sun, Jul 08, 2001 at 04:17:34PM -0400, [EMAIL PROTECTED] wrote:
|
| I tried, in a subdir of /root, the command
| chmod -R o-rwx .*
| It changed the permissions on the parent directory,
| the parent's parent directory, all the way up.
Yes, '.*" includes ".." which is the parent directory.
| Now only root can use my computer.
|
| Was chmod supposed to understand .* so differently
| than /bin/ls does?
No, it doesn't. ls shows the same thing ("ls -R" anyways).
chmod the stuff back to where it should be ;-).
-D
Re: NO! chmod strikes!
On Sun, Jul 08, 2001 at 04:17:34PM -0400, [EMAIL PROTECTED] wrote:
|
| I tried, in a subdir of /root, the command
| chmod -R o-rwx .*
| It changed the permissions on the parent directory,
| the parent's parent directory, all the way up.
Yes, '.*" includes ".." which is the parent directory.
| Now only root can use my computer.
|
| Was chmod supposed to understand .* so differently
| than /bin/ls does?
No, it doesn't. ls shows the same thing ("ls -R" anyways).
chmod the stuff back to where it should be ;-).
-D
NO! chmod strikes!
I tried, in a subdir of /root, the command chmod -R o-rwx .* It changed the permissions on the parent directory, the parent's parent directory, all the way up. Now only root can use my computer. Was chmod supposed to understand .* so differently than /bin/ls does? I am running 2.2.19-pre17 on i586 -josh
