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

SELinux support in backup code #44

Closed
dagwieers opened this issue Mar 30, 2012 · 8 comments
Closed

SELinux support in backup code #44

dagwieers opened this issue Mar 30, 2012 · 8 comments
Labels
enhancement needs sponsorship This issue will not get solved on a voluntary base by ReaR upstream.
Milestone

Comments

@dagwieers
Copy link
Contributor

dagwieers commented Mar 30, 2012

Currently SELinux is disable for backup and we have to fix this.

  • Avoid disabling selinux during backup
    • add --selinux option to tar and testing
    • rsync -X option tests required
@gdha
Copy link
Member

gdha commented Apr 2, 2012

  • reminder for myself - should publish the results of my tests done last year

@bleyers
Copy link

bleyers commented Apr 23, 2012

I have the SELinux policy set on Enforce and I don't have any problems.
The only thing i need to do after the backup (from DP) is restored is
cd /mnt/local
touch .autorelabel

Then i reboot...

@dagwieers
Copy link
Contributor Author

dagwieers commented Apr 23, 2012

If I understand the issue correctly, you loose any SELinux contexts that have manually been modified because neither rsync, nor tar are actually backing up the additional SELinux metadata. I don't know whether DataProtector does it, but since you state you have to force autorelabeling, I doubt DP is doing this correctly either. And you effectively lost any manual modifications.

It is possible DP does not have SELinux support (or extended attributes). Maybe we should make the original report a bit more clear to what is affected and to what extent.

@bleyers
Copy link

bleyers commented Apr 24, 2012

I don't have any real experience with SELinux, I know that it is a security thingie that is usually enabled by default.
When I first tested REAR is couldn't get the recovered machine to work after the reboot.
I then found that I had to relabel the files to get the recovered system to work.
I don't have manually modified anything concerning SELinux so that's why the force autorelabel is no problem for me.

Not having to do the relabel would be great off course..

@dagwieers
Copy link
Contributor Author

dagwieers commented Apr 24, 2012

@bleyers Don't get me wrong, I value your input. For one it helps us to clarify what we still need to do, and in some cases (maybe DP ?) we may as well have to let Rear automatically relabel the filesystem(s) in order to make it boot. So any feedback to our tickets helps us stay on track and clarify what is needed (until someone comes around and implements it ;-))

@dagwieers
Copy link
Contributor Author

dagwieers commented Jun 7, 2012

Relabeling my filesystem took more than 10 minutes, and any custom labels would have been lost. So this issue need to be fixed if we want to have fast and seamless restores with SELinux.

@gdha gdha modified the milestones: Rear v1.19, Rear v1.17 Jan 4, 2015
@gdha gdha modified the milestones: Rear future, Rear v1.19 Sep 5, 2016
@gdha gdha added the needs sponsorship This issue will not get solved on a voluntary base by ReaR upstream. label Sep 5, 2016
@gdha
Copy link
Member

gdha commented Sep 5, 2016

Due to time pressure (for new release) and lack of interest of the community we push this feature forward.

@gdha
Copy link
Member

gdha commented Sep 7, 2016

Added it to the sponsor list - close it

@gdha gdha closed this as completed Sep 7, 2016
N3WWN referenced this issue Mar 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement needs sponsorship This issue will not get solved on a voluntary base by ReaR upstream.
Projects
None yet
Development

No branches or pull requests

3 participants