Have you ever messed up the system’s ownership and/or permissions accidentally? Or maybe you used an application who did that for you? Whichever it was, if that ever happened to you, you’ll be very familiar with what do unstable and unusable system mean. As well as, it could cause in a serious security’s issues.
My Story:
Well,.. I did. ..Ops!!
I was doing just fine with rsync (wiki) for a semi-live mirroring, and CrashPlan (wiki) for the incremental snapshots. Until I thought it wasn’t enough and I should not really rely on one backup tool. And from there the nightmare began, I mean the story. Although I do have a point there, but my mistake was experimenting on a live production system. Which is really really a bad idea.!
Three days ago, I was experimenting a bunch of backup’s tools and applications. Unfortunately, one of those applications was Back In Time (wiki) it messed up my life for a whole two days. Anyway, when I installed it, I found there were two versions of it. The Back In Time
and Back In Time (root)
. And since I wanted to backup the /boot
, /etc
, /home
, /lost+found
, /opt
, /root
, /srv
, /usr
and /var
. I needed to be root in order to read those directories contents to back them up. That’s why I used Back In Time (root)
.
Then, I prepared the remote location on my backup server. And decided to enable the EncFS (wiki) encryption feature that was available in Back In Time application with SSH since the destination is a remote location. And everything was just okay.. At least that’s how I felt back then, specially when the snapshot was being taken successfully.
The next day:
I was able to see the /root
contents. I mean my normal daily used user was able to read and write to /root
, /boot
, /usr
…etc. WTH! I said! When I checked their permissions I found that they were really a mess. Some of them were even being owned by my user instead of the right owner.!
I ran to the older snapshots I have, that were taken by CrashPlan, and compared the permissions. Guess what? Yeah you’re right they were indeed different. Then I realized that, there must be a real nasty bug in the Back In Time. Fortunately, I was lucky enough to discover this issue before it was kinda too late.
My first attempt:
I tried to restore the permissions and ownership via
msec tool which is a nice feature of Mageia Control Center (aka: Drakconf) in Mageia Linux. But that didn’t solve all the problem. So I’ve tried the terminal way: $ msecperms -e
. That didn’t work either.
Why? Well, the msec
is meant to watch some pre-defined particular directories and files permissions and ownership, then restore them if it needs to. Not all of the system’s directories and files.
My second successful attempt:
Okay, because I couldn’t find any already made tool for this job. I thought I should give it a try first. Besides, it should be really easy specially if I have a backup that holds the correct ownership and permissions of each file and directory.
Enough chit-chat, let’s do Linux:
There two things that should be restored. First is the owner of that file or directory. And to which group does it belong to. Second is the Octal permissions it has.
Restoring the ownership:
First, go inside the backup directory you would like to restore the contents ownership from. Let’s assume it’s /mnt/backups/etc
.
$ cd /mnt/backups/etc
Then use find
to list everything inside it:
$ find . ! -type l -exec chown -v --reference='{}' /etc/'{}' \; | grep -v retained
What we did up there, is listing everything except symbolic-links, then we copied the ownership of it to the same file lives in our used system in the directory /etc
.
- The
! -type l
is to list everything that is not sym-link. - The
-exec
is to execute the passed command. - The
chown
is the command we need to call. Which is the one that let us to change the ownership of a file or directory. - The
-v
is to makechown
verbose. - The
--reference=
is to tellchown
that we need to use the same ownership of the passed file. - The
'{}'
is the result of thefind
command. We put it in quotation marks to protect it if it has any spaces or special-characters. - The
/etc/'{}'
is the location of the file we want to apply the ownership to. - The
\;
is to separate each result with a newline. So, instead of callingchown
once for all the results, we call it for each result. This is a good practice if you exceed the maximum allowed passed arguments. - The
|
is to redirect the output to another command. - The
grep -v retained
is to list only the affected files, instead of printing everything. By excluding any output has the word “retained“.
Then just repeat the process to all directories you need to restore their content’s ownership. Like: /boot
, /usr
, /var
…etc.
Restoring the Octal permissions:
We can use the previous script to restore the permissions by replacing the chown
with chmod
. But that won’t be enough. Since it won’t restore the special-permission. Instead it will only restore the permissions of User, Group and Other. So, we need to find another way.
Again, Let’s assume our backup directory is /mnt/backups/etc
. But first we need to prepare and generate a bash script. So, let us create the script in the directory we need to restore the octal-permissions to NOT from. Since we are in /mnt/backups/etc
, it means we should create the file inside /etc
:
$ echo -e '#!/bin/bash\n\n' > '/etc/restoreOctal.sh'
Now, that we created that file, let’s go inside the /mnt/backups/etc
:
$ cd /mnt/backups/etc
Now, let’s generate the rest of the script by listing all the files and directories octal-permissions and store them to /etc/restoreOctal.sh
:
$ find . ! -type l -exec stat -c "chmod %a -v \"%n\" | grep -v retained" "{}" \; >> '/etc/restoreOctal.sh'
What we did up there was: Search all the contents inside the current directory we’re in. And list everything that is not a symbolic-link. Then pass each result to the command stat
then store the output of that command into /etc/restoreOctal.sh
.
- The
stat
is the command we want to apply on every output of thefind
results. - The
-c
is the argument to specify the FORMAT that we want to print instead of the default behavior. - The
chmod
is the command we want to use later when we call therestoreOctal.sh
. - The
%a
is the shortcut of the octal-notation (Octal permission) of the processed file bystat
. - The
%n
is the shortcut of the processed file bystat
. - The
>>
is to redirect the output to a file appending the redirected output at the end. - The
/etc/restoreOctal.sh
is the file we want to store the outputs in.
Then, go to /etc
:
$ cd /etc
Now, let’s make it executable:
$ chmod u+x restoreOctal.sh
Before executing it, let’s take a quick look into its contents just in case there is something wrong with it:
$ vim restoreOctal.sh
If everything looks ok, it’s time to restore those Octal-permissions:
$ ./restoreOctal.sh
Congratulations! You’ve just successfully restored the ownership and octal-permissions to the all contents of your /etc
. Don’t forget to remove the restoreOctal.sh
.
$ rm -f restoreOctal.sh
Then just repeat this process to any directory you’d like to restore its contents octal-permissions.
Finally, Happy Linux-ing 😉
Hi,
can you please add your “story” and some more technical details and how to reproduce the problem in this Issue
https://github.com/bit-team/backintime/issues/819
Hi,.
Sure.. I will.