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