Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backup jobs don't preserve permissions/ownership #201

Open
ghost opened this issue Mar 9, 2017 · 33 comments
Open

Backup jobs don't preserve permissions/ownership #201

ghost opened this issue Mar 9, 2017 · 33 comments
Labels
kind/enhancement kind/proposal status/not-planned-patch-welcome Core developers don't plan to work on this but will gladly accept patches

Comments

@ghost
Copy link

ghost commented Mar 9, 2017

Hi,

So we are testing elkarbackup and I ran into an issue where backups are in the 'elkarbackup' user permissions. In the client part under rsync attributes it mentions that the '-a' flag is on by default and ive added the -p flag to bring the permissions over as well but in the end all files are owned by 'elkarbackup' user and group.

At first glance I could not find a way how to preserve permissions while doing a backup (file ownership and permissions)

@xezpeleta
Copy link
Contributor

Hi @MihkelParna

From Rsync manual:

-p, --perms : preserve permissions
-o, --owner: preserve owner
-g, --group: preserve group

@ghost
Copy link
Author

ghost commented Mar 10, 2017

I've tried all of the options and they don't have an effect on the owner. The ending permissions are still 'elkarbackup'.

@antton
Copy link
Contributor

antton commented Mar 10, 2017 via email

@JamesColeman-SH
Copy link

JamesColeman-SH commented Mar 10, 2017

You can edit /etc/cron.d/elkarbackup to change owner of the tick cron to root. That allows ownership preserving.

After doing this, you will need to copy the .ssh folder from the elkarbackup home directory to the root user.

@feiltom
Copy link

feiltom commented Mar 14, 2017

hello
i backup with Rsync long args --rsync-path="sudo rsync" --fake-super
execute command for restore from client with the --fake-super
and permissions/ownership was preserve

@rderksenMM
Copy link

rderksenMM commented Apr 6, 2017

Regarding the --fake-super , it needs user_xattr mount option, which isn't included in the fs mount "defaults, for the ownership infos to be written in xattrs..
I also tried to create aliases for rsnapshot, rsync, chmod, chgrp to sudo those commands, but that didnt work.
I'll try to change the owner in the cron and see if that works

@rderksenMM
Copy link

Changing to execute as root user in the cron preserved the ownerships. It'll work for now, cheers

@xezpeleta
Copy link
Contributor

@rderksenMM does it work the file browsing under the "Restore" option? Can you restore a file preserving the permissions and the ownership?

Thanks

@rderksenMM
Copy link

rderksenMM commented Apr 6, 2017 via email

@xezpeleta
Copy link
Contributor

but then the file permissions changes obviously to the user that I am downloading the file with

In theory you can download the tgz file and decompress it as root/sudo. It will preserve the correct permissions and ownership.

@rderksenMM
Copy link

rderksenMM commented Apr 6, 2017 via email

@JamesColeman-SH
Copy link

I just did an experimentation to see how things are.
If the user www-data cannot read a file, it will result in a 500 error when attempting to download via the web UI or not even show up when downloading a tar.gz of the folder which it is in within the web UI.

File is still backed up, no matter the ownership or privileges if the tick cron runs as root. But restore via the web UI may vary.

The issue mentioned above isn't an issue for me as I will likely just restore files via rsync anyway to preserve ownership. I'm thinking Elkar should implement an rsync restore function in the web ui similar to what is described at #203

@rderksenMM
Copy link

agreed with James, same here

@gvdijnsen
Copy link

Running the built-in web server as root (I have it running through an Apache proxy) solves the permission problem. Although this seems stable, there may be security issues to this... But for us this works.

@antton
Copy link
Contributor

antton commented May 9, 2017

Could you explain how did you do that @gvdijnsen we can document it then if someone else likes the solution!

Thanks!

@JamesColeman-SH
Copy link

As far as documentation, you can edit /etc/apache2/apache2.conf and look for the line with the User configuration. It is on line 109 in the configuration on my system. Replace both the User and the Group configuration with the below.

User root
Group root

Then restart the computer or restart the service.

On Debian 8 (or any other SystemD based system)

systemctl restart apache2

On Debian 7 (or any other init based system)

service apache2 restart

Where the Apache configuration is located can differ from machine to machine, for an example in CentOS: /etc/httpd/conf/httpd.conf

@antton
Copy link
Contributor

antton commented May 9, 2017 via email

@JamesColeman-SH
Copy link

@antton I can't exactly read minds or anything, but that would be the way I would run Apache as root. The way @gvdijnsen did it could be totally different, and yes... It can be a HUGE security risk. For an example, if a flaw is found to where someone can pass any code to execute on the remote machine, that means they will have root access and be able to inject a root kit on your system.

@gvdijnsen
Copy link

@JamesColeman-SH @antton what I did was the following:

I entered this in a /etc/cron.d/elkarbackup:

# Every minute check for elkarbackup jobs and execute as root:
* * * * *	root	/usr/share/elkarbackup/app/console elkarbackup:tick
# Start the internal php server as root. Apache uses proxxypass to access the server:
@reboot		root	sleep 60; /usr/share/elkarbackup/app/console server:start

This causes the internal web server to start up.

Then I created a virtualhost in Apache that handles the SSL layer and proxies the request. This also helps security a litttle since only valid http requests will be forwarded and the internal web server is protected somewhat:

<VirtualHost *:443>
    ServerAdmin ict@mydomain.com
    ServerName backup.mydomain.com
    ServerAlias backup

    DocumentRoot /usr/share/elkarbackup/web

    <directory /usr/share/elkarbackup/web>
        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule ^(.*)$ app.php [QSA,L]
        AllowOverride None
    </directory>

    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/mydomain.com.crt
    SSLCertificateKeyFile   /etc/ssl/private/mydomain.com.key
    SSLCertificateChainFile /etc/ssl/certs/mydomain.com.ca-bundle

    ErrorLog ${APACHE_LOG_DIR}/elkarbackup-ssl.error.log

    ProxyPass / http://127.0.0.1:8000/
    ProxyPassReverse / http://127.0.0.1:8000/

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    CustomLog ${APACHE_LOG_DIR}/elkarbackup-ssl.access.log combined
</VirtualHost>

Please note: This only works if you enable the proxy and the proxy_http modules in Apache.

Because everything is behind a firewall I am willing to live with the possible security consequences, but be careful if you open this to the Internet.

@vassiskansa
Copy link

vassiskansa commented Oct 17, 2017

Hi,
I've tried to change root in the cron file, but seems it doesn't work for me.
Error report:

Command "/usr/bin/rsnapshot" -V -c "/tmp/rsnapshot.1_31.cfg" sync 2>&1 failed. Diagnostic information follows: Setting locale to POSIX "C" echo 12965 > /tmp/rsnapshot.0001_0031.pid mkdir -m 0755 -p /mnt/backup-server/0001/0031/.sync/ /usr/bin/rsync -av --delete --numeric-ids --relative --delete-excluded \ --chmod=Fug=rwX,Dug=rwx,Fo=r,Do=rx --stats --rsh=/usr/bin/ssh -o \ BatchMode=yes -o StrictHostKeyChecking=no \ root@xxx.xxx.xx:/var/log \ /mnt/backup-server/0001/0031/.sync/. receiving incremental file list var/ rsync: chgrp "/mnt/backup-server/0001/0031/.sync/var/log"

Here how i mount /mnt/backup-server (fstab)

/xxx.xxx.xx/backup /mnt/backup-server cifs iocharset=utf8,rw,credentials=/etc/backup-credentials.txt,uid=0,gid=0 0 0

I've tried to switch on and off "Use local permissions" on the job.
Can anyone help me?
Sorry for the spam...

@antton
Copy link
Contributor

antton commented Oct 18, 2017

Hi @vassiskansa

Could you explain what are you trying to do?
Are making a copy of a Windows machine or Linux machine?
Why you need to change the cron to use root user? As you could read on this thread is not really secure at least if your installation has an external access.

Anyway, let us know something more, it looks like you have problems with the ACLs but I'm not completly sure about that.

Thanks!

@vassiskansa
Copy link

Hi @antton , i'm trying to backup many linux servers. I've tried to make cron execution by root but the problem is already here. My hosting has many problem to change owner of the file, however i'm trying to bypass this (rsync work very well, but there is a warning changing file owner).
I hope that i've answer your question, @antton . Thank you for reply.

@sgregori
Copy link

sgregori commented Apr 18, 2018

After each elkarbackup upgrade, at least for 2 times, i found this command running on background:

chown -R elkarbackup.elkarbackup /var/cache/elkarbackup /var/log/elkarbackup /var/spool/elkarbackup

is it normal ?

Seems to be overwriting ownership for the backups directory...

image

@xezpeleta
Copy link
Contributor

Seems to be overwriting ownership for the backups directory...

Hi @sgregori , yes it's normal. Does it cause any problem in your system? In this case, is it somehow related to this issue or is a new one?

Thanks

@sgregori
Copy link

@xezpeleta , can you boot any backup without the correct permissions ?

I have a daily getfacl cronjob, for easy restoring acl's in case of disaster.
In my opinion, the normal is that the backup must preserve owner and permissions.
There are another way to restore with correct permissions ?
Thanks

@xezpeleta
Copy link
Contributor

In my opinion, the normal is that the backup must preserve owner and permissions.
There are another way to restore with correct permissions ?

I see, but currently that's not possible with Elkarbackup. I know there are some workarounds (see comments above), but not officially supported by Elkarbackup.

The thing is: it's not trivial to do it. There are some features that would broke (like web access to backup files). Or you need to set up your system in a non-secure way (like apache running with root user). So that's why it's still pending.

@xezpeleta xezpeleta added this to the 1.4.0 milestone May 17, 2018
@xezpeleta
Copy link
Contributor

Hi, we've been exploring a different approach to do that, using facl and a script:

https://github.com/elkarbackup/elkarbackup-scripts/tree/master/backup-permissions

I think it's an easy / secure way to achieve the permissions/ownership preservation. The only drawback is that the restore needs two steps: one to obtain the files and another one to recover the permissions using facl. On the other hand, that can give you more flexibility.

@xezpeleta xezpeleta removed this from the 1.4.0 milestone Jul 19, 2018
@arnaudmuse
Copy link

arnaudmuse commented Jan 8, 2019

Hi everyone , new fresh install of elkarbackup on debian 9 , and all files saved are elkarbackup:elkarbackup owner/group and permission files ommitted too. I don't understand why. I've try to mod copyrepository.sh added pog arguments to the rsync command, clear the cache of symfony. I can see the changes via the elkar interface showing the backupscript but no effect

Thanks for advance

@elacunza
Copy link
Contributor

This is by design and as @xezpeleta said non-trivial to fix.

@elacunza elacunza added status/not-planned-patch-welcome Core developers don't plan to work on this but will gladly accept patches and removed kind/question labels Apr 21, 2021
@igorbga
Copy link

igorbga commented May 3, 2021

Just a tip in case someone catches on this issue and really tries to give a solution to this by design limitaion.

Maybe we could preserve original permissions and do a wise use of mount options in order to avoid SUID execution. Or maybe we could even try to restrict access to backup files with Apparmour (or SELinux: https://security.stackexchange.com/questions/30116/restrict-access-to-a-specific-directory-on-linux )

Then we could use "bindfs" (https://bindfs.org/) to make the files accesible for Elkarbackup's restore web interface.

Not a simple an obvious task but probable doable and quite robust if done properly.

@elacunza
Copy link
Contributor

elacunza commented May 3, 2021

Note I just found a bug that affected local permission backups on upgrade: #529

@JoshuaPettus
Copy link

@igorbga, I'm just the peanut gallery, but I have to say that sounds at least an excellent way for this project to move forward

@larsfessler
Copy link

You can edit /etc/cron.d/elkarbackup to change owner of the tick cron to root. That allows ownership preserving.

After doing this, you will need to copy the .ssh folder from the elkarbackup home directory to the root user.

Did that too. The GUI can still access the files. File and tar download still work.
I will try restore to client as soon as #543 is fixed and released. I'm very curious about that.

I will put a remark into our own documentation to check the cron job on every ELKARbackup update.

Thanks to @JamesColeman-SH for this great workaround!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement kind/proposal status/not-planned-patch-welcome Core developers don't plan to work on this but will gladly accept patches
Projects
None yet
Development

No branches or pull requests