On Tuesday 01 August 2006 22:22, Paul Howarth wrote: > On Tue, 2006-08-01 at 19:30 +0200, J.L. Coenders wrote: > > On Tuesday 01 August 2006 18:15, Paul Howarth wrote: > > > J.L. Coenders wrote: > > > > On Tuesday 01 August 2006 13:02, Paul Howarth wrote: > > > >> J.L. Coenders wrote: > > > >>> Hi, > > > >>> I am trying to automate a backup with rsync to a second disc using > > > >>> a cronjob. I am running fc5. The script works fine when I run it > > > >>> manually, but if I try to run it as a cronjob it fails with a lot > > > >>> of rsync errors. When looking at the system logs, I suspect that > > > >>> SELinux is blocking rsync. How do I correct this? > > > >>> > > > >>> Messages are like this: > > > >>> > > > >>> Aug 1 09:09:43 localhost kernel: audit(1154416183.900:651): avc: > > > >>> denied { search } for pid=19905 comm="rsync" name="/" dev=sda1 > > > >>> ino=2 scontext=system_u:system_r:rsync_t:s0 > > > >>> tcontext=system_u:object_r:default_t:s0 tclass=dir > > > >> > > > >> That may be a labelling problem on your system. > > > >> > > > >>> Could anyone show me to some easy to understand explanation of > > > >>> SELinux? So far I only find quite complex ones. > > > >> > > > >> SELinux isn't simple, so you're unlikely to find a simple > > > >> explanation for it. > > > >> > > > >> What is the top-level directory you are trying to copy using rsync? > > > >> > > > >> Paul. > > > > > > > > Hehehe, thanks, I already understood that it probably would not be > > > > simple. One of the Linux magazines I consulted said something similar > > > > to that too. > > > > > > > > I am trying to rsync my home, /etc and /var directory to a backup > > > > drive. So that would be /home/user, /etc and /var. > > > > > > There's no way the standard SELinux policy is going to let you do that, > > > as there are loads of "sensitive" files there that people shouldn't > > > normally be able to access using the rsync service. Given the number of > > > different file types involved, particularly for /etc and /var, it's not > > > practical to change the rsync policy ro allow access to all of these > > > files. > > > > > > One way to fix this would be to disable the transition to the rsync_t > > > domain, so that rsync ran "unconfined" by SELinux when run from cron, > > > just as it does when run manually. > > > > > > That's a bit of a sledgehammer approach though. Can you tell us exactly > > > how you are trying to do this? rsync command directly in crontab file? > > > Are you running rsync locally or over the network? Are you using a > > > wrapper script? > > > > > > And can you post the output of: "sestatus" > > > > > > Paul. > > > > Hi, > > The thing I would like to do, is make a nightly backup of these > > directories. I have made a script for it (attached), which I run using > > cron, basically rsyncing the directories to a backup disk (usb). > > Probably it is not the most beautiful script, but it ran quite nicely > > before. If anyone would like to use it, feel free. > > > > [sestatus output] > > SELinux status: enabled > > SELinuxfs mount: /selinux > > Current mode: enforcing > > Mode from config file: enforcing > > Policy version: 20 > > Policy from config file: targeted > > The script looks fine to me. I'm a bit surprised it's running in the > "rsync_t" domain though, as cron jobs here seem to run "unconfined" as > if you'd just run them manually. > > Where is the script installed? > > Can you post the output of: > > $ ls -lZ /path/to/script > > Oh, and one last thing: > > # ls -lZa / > # restorecon -v / > # ls -lZa / > > What do you get for those? If the second "ls" output is different from > the first, try the cron job again and see if you get different results. > > Paul. Somehow, last night the automated backup worked perfectly without any tinkering to it. It must have had something to do with the way I was trying to test the cronjob, through Webmin. Thanks for the help anyway, guys. Cheers, Jeroen
Attachment:
pgpbdxF9RhaM4.pgp
Description: PGP signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list