chmod every file to 777
mich...@email.it
sudo chmod -R 777 /opt/somedir...and then something awful, that i dont
write here because it could be mis-interpreted as a malicous command
the result is that now each and every file in my system has permission
777
lovely i would say
:-(((
i've fixed the /etc/sudoers permissions back to 440 ....
the best thing i can imagine for now is "chmod" every system folder to
more restrictive permissions: very annoying, to say the least.
Or maybe: save my foders and reinstall (i would HATE it);
or, probably better restore the backup of may partition, it' one week
old.
It could be a choice, but i'll be grateful for every suggestion...
some clever shell script ....
Thank you in advance
rcp
...
> or, probably better restore the backup of may partition, it' one week
> old.
In the past I did something just as clumsy. Like you I had a backup
that was a few days old. What I did was copy the current mess to a new,
empty, partition then do the restore. I copied back the things I knew were
out of date and left the original data lying around for a while (months,
actually) until I was sure I got everything I needed from it.
Bob
Joachim Schmitz
If you have a backup, even an older one, you may be able to use it's
permissions, i.e. list the archive content, extract fthe names of the files
and their permissions and to the chmod with this.
Depending on which installation method is used with this bmachine, the
package management may have the ability to check desired permissions. As far
as I remember the SysV pkg tools can do this and I think Linux' rpm can do
it too.
Bye, Jojo
jellybean stonerfish
It doesn't sound difficult to fix. Make a script to read through your
backup. Find the permissions of each file, and change the existing
permissions to match. If you tell us how you made your backup (tar, dd,
cpio, etc ) someone may help you write one.
sf
mich...@email.it
>partimage -z save /dev/sda1 /mnt/disc ...
hmm, i'm too newbie to write such script, probably the best thing *for
me* will be to follow rcp suggestion.
thanks to all that took the time to answer me
:-)
On Nov 21, 3:37 pm, jellybean stonerfish <stonerf...@geocities.com>
wrote:
mich...@email.it
> package management may have the ability to check desired permissions. As far
it's kubuntu 8.04, not "really" linux, i know
mich...@email.it
> > Depending on which installation method is used with this bmachine, the
> > package management may have the ability to check desired permissions. As far
>
houghi
In openSUSE there is a 'repair' that you can do from the CD/DVD that
will put most of the things back to how they should be. Perhaps Kubuntu
has also such a thing.
OTOH I would think that this is why I have incremential backups taken
twice a day. I had it happen with a `chown -R houghi:users *` while I
was in /bin instead of /home/houghi/bin.
houghi
--
This was written under the influence of the following:
| Artist : Clara Haskil & Arthus Grumiaux
| Song : Sonata No. 3 in E flat, Op. 12 No 3 - 1st Movement
| Album : The Violin Sonatas Beethoven
viza
> the backup is with partimage
>>partimage -z save /dev/sda1 /mnt/disc ...
> hmm, i'm too newbie to write such script, probably the best thing *for
> me* will be to follow rcp suggestion. thanks to all that took the time
> to answer me :-)
Don't give up so easily!
Correct the file system type and image file name, and also then wait a
few hours to see if anyone else corrects this: (untested)
#/bin/bash
mkdir /backup || exit
mount -t fstype -o ro,loop image /backup || exit
printf -v IFS '\0'
for baup in find /backup -print0
do
orig="${baup%%/backup}"
mode=`stat -c'%a' "$baup"`
[ $? = 0 ] && [ -e "$orig" ] && chmod $mode "$orig"
done
Geoff Clare
> On Fri, 21 Nov 2008 06:47:14 -0800, michiedo wrote:
>
>> the backup is with partimage
>>>partimage -z save /dev/sda1 /mnt/disc ...
>> hmm, i'm too newbie to write such script, probably the best thing *for
>> me* will be to follow rcp suggestion. thanks to all that took the time
>> to answer me :-)
>
> Don't give up so easily!
>
> Correct the file system type and image file name, and also then wait a
> few hours to see if anyone else corrects this: (untested)
>
> #/bin/bash
>
> mkdir /backup || exit
> mount -t fstype -o ro,loop image /backup || exit
>
> printf -v IFS '\0'
>
> for baup in find /backup -print0
Presumably that was meant to be:
for baup in $(find /backup -print0)
> do
> orig="${baup%%/backup}"
> mode=`stat -c'%a' "$baup"`
> [ $? = 0 ] && [ -e "$orig" ] && chmod $mode "$orig"
> done
The script needs to ignore symlinks, otherwise if it processes a
symlink after the target of the symlink, it will end up assigning
the permissions of the symlink to the target file.
I.e. use ... $(find /backup ! -type l -print0)
--
Geoff Clare <net...@gclare.org.uk>
Stephane Chazelas
[...]
>> #/bin/bash
>>
>> mkdir /backup || exit
>> mount -t fstype -o ro,loop image /backup || exit
>>
>> printf -v IFS '\0'
>>
>> for baup in find /backup -print0
>
> Presumably that was meant to be:
>
> for baup in $(find /backup -print0)
Wouldn't work with bash. zsh is a the only shell that I know of
that can store a NUL byte in its variables (and actually the
default value of $IFS in zsh actually contains the NULL byte)
zsh is also the only Bourne-like shell that doesn't perform
globbing upon command substitution by default. In other shells,
you'd need to issue a "set -f" to disable globbing.
$ echo '/et*\0foo\0' | ksh -c "IFS=\$'\0'; printf '<%s>\n' \$(cat)" | cat -vt
</etc>
$ echo '/et*\0foo\0' | bash -c "IFS=\$'\0'; printf '<%s>\n' \$(cat)" | cat -vt
</et*foo>
$ echo '/et*\0foo\0' | zsh -c "IFS=\$'\0'; printf '<%s>\n' \$(cat)" | cat -vt
</et*>
<foo>
<>
$ echo '/et*\0foo\0' | zsh -c "printf '<%s>\n' \$(cat)" | cat -vt
</et*>
<foo>
<>
--
Stéphane