Backup jobs don't preserve permissions/ownership

[ghost]

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]

Hi @MihkelParna

From Rsync manual:

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

[ghost]

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

[antton]

Where did you install? Debian? Ubuntu?

Which version?

El 10 mar 2017, a las 11:13, Mihkel Pärna [email protected] escribió:

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[JamesColeman-SH]

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]

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]

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]

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

[xezpeleta]

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

Thanks

[rderksenMM]

I can browse to the file and download it from the web interface, but then the file ownership changes obviously to the user that I am downloading the file with. I'm new to elkarbackup so I don't know if there is a "restore" button somewhere in the web interface?

In any case if I go in command line and "rsync -a" to restore the file, it restores fine and keeps the ownership, so that is fine for me.

Best, RD

On 04/06/2017 03:35 PM, Xabi wrote:

@rderksenMM https://github.com/rderksenMM does it work the file browsing under the "Restore" option? Can you restore a file preserving the permissions and the ownership?

Thanks

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elkarbackup/elkarbackup/issues/201#issuecomment-292176352, or mute the thread https://github.com/notifications/unsubscribe-auth/AZtxUsoH9Xc1YTw_85BTzY6J0q-HQMwAks5rtOokgaJpZM4MYWLQ.

--

Attention: Confidential

This email message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact me by reply email and destroy all copies of the original message.

[xezpeleta]

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]

ok thanks for the info. I actually just tested with a file, and the tgz option is only available for directories. I'll try with a directory.

On 04/06/2017 04:06 PM, Xabi wrote:

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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elkarbackup/elkarbackup/issues/201#issuecomment-292184937, or mute the thread https://github.com/notifications/unsubscribe-auth/AZtxUg2KHEn2ogetiiJM0AckUntbPbn0ks5rtPFJgaJpZM4MYWLQ.

--

Attention: Confidential

This email message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact me by reply email and destroy all copies of the original message.

[JamesColeman-SH]

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 https://github.com/elkarbackup/elkarbackup/issues/203

[rderksenMM]

agreed with James, same here

[gvdijnsen]

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]

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

Thanks!

[JamesColeman-SH]

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]

OK!

I didn't understand what you mean with an apache proxy!

As you said this solution is not really secure for your system, but if going to be only for an internal network could be a solution.

We would think about it!

Thanks!

2017-05-09 14:53 GMT+02:00 JamesColeman-SH [email protected]:

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

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/elkarbackup/elkarbackup/issues/201#issuecomment-300153225, or mute the thread https://github.com/notifications/unsubscribe-auth/ABlt9CUdrzTqobXccR80cvzYrteBBJ1Nks5r4GGwgaJpZM4MYWLQ .

[JamesColeman-SH]

@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]

@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 [email protected]
    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]

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 \ [email protected]:/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]

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]

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]

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...

[xezpeleta]

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]

@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]

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]

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.

[arnaudmuse]

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]

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

[igorbga]

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.