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:
pgpvFOVee6oaq.pgp
Description: PGP signature
