[mintbackup] saves folders/files with "root" as the owner

Bug #569261 reported by flan_suse on 2010-04-24
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Linux Mint
Low
Clement Lefebvre

Bug Description

mintbackup 2.0.2

Testing out the Backup Tool 2.x on Helena (which will be included in Isadora) I found out that it saves the software list with the user "root" as the owner of the file, and even the folder if "Create new folder" is done.

1.) Run the Backup Tool 2.0.2
2.) Select "Backup software selection"
3.) Under "Destination" select "Other" and create a new folder in your home directory called "software_list"
4.) Click "Forward" then "Apply"

If you check the permissions of the folder and file, it looks like this:

drwxr-xr-x root root software_list
-rw-r--r-- root root software_selection_linux-mint@2010-04-23-2116-package.list

The file and folder cannot be deleted, even if saved in your own home directory, unless you use the sudo command in a terminal.

This seems counter-intuitive for the Backup Tool.

A correction: The same problem occurs when backing up the user's files.

Changed in linuxmint:
importance: Undecided → Low
status: New → Confirmed
milestone: none → isadora-stable
assignee: nobody → Clement Lefebvre (clementlefebvre)

Not sure how its counter intuitive as the application is meant to be a backup tool, which you
would later use to restore the same fie on another computer. Saving UID's other than root
makes little sense. However there is a possibility, once the tool has written the backup
list to disk, it could then proceed to set world-read/write permissions on the file (a+rw),
which would solve the issue of moving/deleting lists when not root, and avoid file managers
complaining about non-existent users etc.

flan_suse (flansuse) on 2010-05-06
description: updated
flan_suse (flansuse) wrote :

Counter-intuitive in the sense that a user cannot undo his own backup, unless manually removing it in the terminal using sudo.

It seems odd, because if a user wants to backup his home folder, or a subfolder within his home, then why would he need to run the backup application with root privileges? And once he does make a backup, even as a .tar.gz, he cannot access the files within; not even being able to extract them, unless he does: sudo tar xfvz mybackup.tar.gz

In the IRC channel, you explained the reason behind root privileges for backing up the software list, which is needed for locking the apt cache.

I agree with your solution, to save the backups and the software list with full read/write permissions: -rw-rw-rw-

The newly created folders within the application should also have full read/write permissions. Right now, browsing for the backup destination and creating a new folder within the Backup Tool will create a folder that only root can delete.

flan_suse (flansuse) wrote :

Is is possible to run the Backup Tool as a normal user when using the folder/file backup? Such as the option to run it with normal user privileges?

Perhaps, the tool can be run as a normal user, and the interface will have an "Unlock" icon to run it with root privileges? This is how the Users Admin tool works: http://www.ubuntugeek.com/wp-content/uploads/2009/11/22.jpg

flan_suse (flansuse) wrote :

You will notice in that link that only the current user's account can be modified, unless they "Unlock" root privileges, in which *all* user accounts can be modified. Something in the Backup Tool could work the same way:

1.) Backup Tool is run as the normal user.
2.) Backing up the Software List is greyed out; only backing up the user's home folder/files as available.
3.) Clicking on the "Unlock" icon will ask for the root/user password.
4.) After unlocking root privileges, the Software List oprion is no longer greyed out.
5.) Even when running with root privileges, the permissions will still be: rw-rw-rw-

I hope this make sense and helps make the Backup Tool more friendly.

remoulder (remoulder) wrote :

Seems a little more complex here. After using the tool from a USB install of Isadora to backup my home from Helena on the HDD, I was left with all files and folders in the root of home owned by my user's UID ( which is the same on Isadora as Helena), but seeming random folders having all sub-folders owned by root. Hope this makes sense. Also the 'backup' seems to be just a straight copy, why is there no compression, or have I missed that?

Fixed in mintbackup 2.0.5. Software selection file is now chmoded to "a+rw" while its containing directory is made "a+rx".

Changed in linuxmint:
status: Confirmed → Fix Released
flan_suse (flansuse) wrote :

Good news to hear! There is one problem I did not mention earlier, but the same thing applies to the file/folder backup feature as well, which you can see in my edited bug report and from a user's comment above in comment #5.

The subfolders and files are saved with "root" as the owner, without the read/write permissions for the normal user. This will happen wether or not compression is used. If compression is used, the contents of the .tar.gz cannot be extracted, because of a permissions issue. Hopefully, the same fix (a+rw) can easily be applied to the file/folder backup feature as well.

flan_suse (flansuse) wrote :

Clem, I think the best way to handle this is by having the backup (whether software list or files/folders) had full a+rw permissions, including the newly created folder.

I'm trying Backup Tool 2.0.6 and the problem still occurs where the folder cannot be deleted, and when using the files/folders backup, they have read-only permissions for non-root users.

flan_suse (flansuse) on 2010-05-20
Changed in linuxmint:
status: Fix Released → In Progress
status: In Progress → Incomplete
Changed in linuxmint:
status: Incomplete → Confirmed
Nick Raptis (airscorp) wrote :

Another repercussion of this bug that I experienced is that having the folders restored as root is that some firefox add-ons (namely Boost for facebook is the one that caught my eye) can't update properly as they try to replace the whole folder.

I'm using 2.0.6 and seeing only folders not going back to prior user/permissions when using tar backup with both preserve options on. Files seem fine.

Changed in linuxmint:
milestone: isadora-stable → julia-rc1
Jarom Feriante (jaromf) wrote :

Please excuse me for being a novice, but I became a victim of this bug ever since I upgraded from Helena to Isadora and restored my backed up files a few months ago. Locked folders have caused issues with certain programs. On occasion, I've managed the issue by restoring permissions to myself using the GUI.

Can anyone recommend a more efficient method for unlocking a folder and all its sub-folders? Thanks in advance!

Changed in linuxmint:
milestone: julia-rc1 → julia-stable
summary: - Backup Tool 2.0.2 saves folders/files with "root" as the owner
+ [mintbackup] saves folders/files with "root" as the owner
Changed in linuxmint:
milestone: julia-stable → julia-maintenance
flan_suse (flansuse) wrote :

Will the fixed version be backported to the LTS release? Like the above comment, the permissions issue is still present in Backup Tool version 2.0.6.

flan_suse (flansuse) wrote :

Hate to bring this up again, but even with 2.0.6, the folder permission/owner issue still exists.

If a new folder is created with the mintbackup tool, it will have root as the owner, and only root can write/delete the folder.

$ rm -rf test/
rm: cannot remove `test/software_selection_my-pc@2011-03-22-1741-package.list': Permission denied

The folder should be created with the user as the owner, with the same permissions as any other folder created with "mkdir".

Right now, the mintbackup tool has speed bumps that need to be flattened.

flan_suse (flansuse) wrote :

It's been quite a while and I'm not sure if this bug is still being looked into? My previous comment still holds true, which doesn't look good for an LTS release like Isadora. Using a friendly GUI tool should never require any user to drop into the command-line to delete the resulting folder with sudo if they wish to move/delete what they just created.

I understand that the Backup Tool must be run with root permissions in order to lock the apt database, but can't this be done alternatively? An example is with Network Manager. You run it as a normal user, but if you wish to modify a global setting (or require root) it will prompt for the password.

Basically, using the Mint Backup Tool should look something like this:

1) User launches the Backup Tool
2) User makes a backup of their files/folders
3) On a later date, User launches Backup Tool
4) User restores from earlier backup
5) Done

Or

1) User launches the Backup Tool
2) User makes a backup of their software list
3) On a later date, User launches Backup Tool
4) User restores installed software
5) Done

That's the idea, right? How to smoothly handle root privileges without interfering with the workflow (e.g, requiring sudo to delete a folder) is up to the developer(s), not the *end-users*. I'm not trying to come off as condescending or rude. This is simply how it is. I can only tell you how I believe the Backup Tool should behave. The coding is up to the Mint *developers*.

The above 5 steps are simple and practical, as the Backup Tool was designed for. That is the goal trying to be achieved. The problem arises when the user has to drop into the terminal (or use an outside method) to work around a bug in the Backup Tool.

Can this bug be looked into? Version 2.0.6 on Isadora (LTS) still contains this bug. Thank you, Mint devs!

flan_suse (flansuse) wrote :

I just tried mintbackup 2.0.7, and the same problem persists. It's been almost two years since this bug was reported, and I was wondering if the mintbackup tool is being re-written or this bug is being worked on?

Marcin Mielniczuk (marmistrz) wrote :

Confirming, the bug persists in 2.1.5

mikeb (mikeb-z) wrote :

Just a post to confirm the bug exists on 2.1.7 (the backup was made with mintbackup 2.1.1 and restored using 2.1.7).

For the record, my backup was to a tar archive. Backed up my home directory in preparation for moving from Mint 16 Petra to Mint 17.2 Rafaela via a clean install. The resulting restore seemed to get all my files back, but wasn't very usable because all of the sub-directories were owned by root.

The workaround:

        sudo chown -R user:user /home/user

repaired the problem.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers