Bug 1234847

Ok this is a problem. What scenario are you testing here?

crond has a SELinux functionality to check if a job can run within a correct cronjob SELinux type. It is done using entrypoint permission. But we have fuse_t instead of system_cron_spool_t here.

allow system_cronjob_t system_cron_spool_t : file entrypoint;

If you add this rule for fuse_t it should work.

# sesearch -s system_cronjob_t -t system_cron_spool_t -c file -p entrypoint -A -C
Found 1 semantic av rules:
   allow system_cronjob_t system_cron_spool_t : file { ioctl read write create getattr setattr lock append unlink link rename entrypoint open } ; 
#

You meant to add following rule, which is not present in current policy:

allow system_cronjob_t fusefs_t:file entrypoint;

This is not something what we want to allow by default. This is a custom setup and I am thinking either about a boolean or about a local policy shipped by Gluster.

(In reply to Miroslav Grepl from comment #4)
> This is not something what we want to allow by default. This is a custom
> setup and I am thinking either about a boolean or about a local policy
> shipped by Gluster.

Hi Miroslav,

If you have the above mentioned boolean or a local policy ready for testing, could you please share it in Bug 1231647 so that QE can test and confirm back?

Could you test it with the following local policy module

# cat mygluster.te
policy_module(mygluster, 1.0)

require{
 type gluster_t;
 type nfs_t;
 type cifs_t;
 type fusefs_t;
}

allow gluster_t nfs_t:file entrypoint;
allow gluster_t cifs_t:file entrypoint;
allow gluster_t fusefs_t:file entrypoint;

# make -f /usr/share/selinux/devel/Makefile mygluster.pp
# semodule -i mygluster.pp

Oops, I apologize. There it should be

# cat mygluster.te
policy_module(mygluster, 1.0)

require{
 type system_cronjob_t;
 type nfs_t;
 type cifs_t;
 type fusefs_t;
}

allow system_cronjob_t nfs_t:file entrypoint;
allow system_cronjob_t cifs_t:file entrypoint;
allow system_cronjob_t fusefs_t:file entrypoint;

Followed steps as mentioned in Comment 7 and scheduler was able to create snapshots.

 snap_scheduler.py list
JOB_NAME         SCHEDULE         OPERATION        VOLUME NAME      
--------------------------------------------------------------------
A1               */5 * * * *      Snapshot Create  vol0             


[root@rhsqe-vm06 ~]# tail -f /var/log/glusterfs/gcron.log 
[2015-07-01 12:45:19,802 gcron.py:100 doJob] INFO Job Scheduled-A1-vol0 succeeded
[2015-07-01 12:50:01,968 gcron.py:178 main] DEBUG locking_file = /var/run/gluster/shared_storage/snaps/lock_files/A1
[2015-07-01 12:50:01,969 gcron.py:179 main] DEBUG volname = vol0
[2015-07-01 12:50:01,969 gcron.py:180 main] DEBUG jobname = A1
[2015-07-01 12:50:01,981 gcron.py:96 doJob] DEBUG /var/run/gluster/shared_storage/snaps/lock_files/A1 last modified at Wed Jul  1 12:45:19 2015
[2015-07-01 12:50:01,981 gcron.py:98 doJob] DEBUG Processing job Scheduled-A1-vol0
[2015-07-01 12:50:01,982 gcron.py:68 takeSnap] DEBUG Running command 'gluster snapshot create Scheduled-A1-vol0 vol0'
[2015-07-01 12:50:20,747 gcron.py:75 takeSnap] DEBUG Command 'gluster snapshot create Scheduled-A1-vol0 vol0' returned '0'
[2015-07-01 12:50:20,747 gcron.py:83 takeSnap] INFO Snapshot of vol0 successful
[2015-07-01 12:50:20,747 gcron.py:100 doJob] INFO Job Scheduled-A1-vol0 succeeded


gluster snapshot list |wc -l 
254


getenforce
Enforcing

rpm -qa |grep selinux
libselinux-debuginfo-2.2.2-6.el7.x86_64
selinux-policy-targeted-3.13.1-29.el7.noarch
libselinux-utils-2.2.2-6.el7.x86_64
libselinux-python-2.2.2-6.el7.x86_64
selinux-policy-devel-3.13.1-29.el7.noarch
libselinux-2.2.2-6.el7.x86_64
selinux-policy-3.13.1-29.el7.noarch

I tried this on a 2 node cluster and found that only one node was picking uo the job , need to look into this further

Tried the latest policy update. With that the file /etc/cron.d/glusterfs_snap_cron_tasks is being picked up by crond. However because /etc/cron.d/gcron_update_task is created by renaming it from a tmp file created in /tmp/crontab it has a different file context which prevents it from being picked up by crond.

In order to resolve this, we need to create /etc/cron.d/gcron_update_task by renaming it from a tmp file created in /var/run/gluster/shared_storage/snaps/tmp_file.


But even with the above change I don't see crond reloading /etc/cron.d/glusterfs_snap_cron_tasks whenever the modified time of the file changes. Am not sure is this is a crond bug for rhel 7.1 or not, but it seems not to reload a file even though the file's last modified time is changed.

Installed the latest Selinux policy build, Scheduler still fails to create snapshots with SELinux in 'Enforcing' mode 

Jul 13 17:21:02 rhsqe-vm05 crond[9994]: ((null)) Unauthorized SELinux context=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 file_context=system_u:object_r:fusefs_t:s0 (/etc/cron.d/glusterfs_snap_cron_tasks)
Jul 13 17:21:02 rhsqe-vm05 crond[9994]: (root) FAILED (loading cron table)
Jul 13 17:21:02 rhsqe-vm05 CROND[10504]: (root) CMD (PATH=$PATH:/usr/local/sbin:/usr/sbin gcron.py --update)
Jul 13 17:22:01 rhsqe-vm05 CROND[10509]: (root) CMD (PATH=$PATH:/usr/local/sbin:/usr/sbin gcron.py --update)
Jul 13 17:23:01 rhsqe-vm05 CROND[10514]: (root) CMD (PATH=$PATH:/usr/local/sbin:/usr/sbin gcron.py --update)

rpm -qa |grep selinux
libselinux-utils-2.2.2-6.el7.x86_64
libselinux-python-2.2.2-6.el7.x86_64
selinux-policy-devel-3.13.1-31.el7.noarch
libselinux-2.2.2-6.el7.x86_64
selinux-policy-3.13.1-31.el7.noarch
selinux-policy-targeted-3.13.1-31.el7.noarch

Set SELinux to 'Permissive' and Scheduler creates snapshots successfully. 

Moving the bug back to 'Assigned'

Created attachment 1051390 [details]
Audit log for comment 13

Does it work when you enable the cron_system_cronjob_use_shares boolean?

I have enabled the boolean as mentioned and Scheduler is able to create snapshots 

getsebool -a |grep cron_system_cronjob_use_shares
cron_system_cronjob_use_shares --> on

rpm -qa |grep selinux
libselinux-2.2.2-6.el7.x86_64
libselinux-python-2.2.2-6.el7.x86_64
selinux-policy-targeted-3.13.1-32.el7.noarch
libselinux-utils-2.2.2-6.el7.x86_64
selinux-policy-3.13.1-32.el7.noarch

snap_scheduler.py list
JOB_NAME         SCHEDULE         OPERATION        VOLUME NAME      
--------------------------------------------------------------------
RHEL7_JOB1       */5 * * * *      Snapshot Create  volume0     

gluster snapshot list 
Scheduled-RHEL7_JOB1-volume0_GMT-2015.07.15-07.45.01
Scheduled-RHEL7_JOB1-volume0_GMT-2015.07.15-07.50.01
Scheduled-RHEL7_JOB1-volume0_GMT-2015.07.15-07.55.01
Scheduled-RHEL7_JOB1-volume0_GMT-2015.07.15-08.00.01
Scheduled-RHEL7_JOB1-volume0_GMT-2015.07.15-08.05.01
Scheduled-RHEL7_JOB1-volume0_GMT-2015.07.15-08.10.01
Scheduled-RHEL7_JOB1-volume0_GMT-2015.07.15-08.15.01


[2015-07-15 14:50:01,627 gcron.py:96 doJob] DEBUG /var/run/gluster/shared_storage/snaps/lock_files/RHEL7_JOB1 last modified at Wed Jul 15 14:45:05 2015
[2015-07-15 14:50:01,628 gcron.py:98 doJob] DEBUG Processing job Scheduled-RHEL7_JOB1-volume0
[2015-07-15 14:50:01,628 gcron.py:68 takeSnap] DEBUG Running command 'gluster snapshot create Scheduled-RHEL7_JOB1-volume0 volume0'
[2015-07-15 14:50:05,869 gcron.py:75 takeSnap] DEBUG Command 'gluster snapshot create Scheduled-RHEL7_JOB1-volume0 volume0' returned '0'
[2015-07-15 14:50:05,870 gcron.py:83 takeSnap] INFO Snapshot of volume0 successful
[2015-07-15 14:50:05,871 gcron.py:100 doJob] INFO Job Scheduled-RHEL7_JOB1-volume0 succeeded

cleared need info while adding comment18, adding it back

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2300.html