User and Group quota is not working on RHEL6.2 ext4/ext3

Hello!

I am in a weird problem of not able to set quota on an ext4 file system. I have setup a logical volume on which this ext4 filesystem resides. It's going to be used by an application for dumping data. But we want to setup quota so that it does not consume all the free space of the lv. The application will generate an error log if the quota limit is crossed. But the problem is that I am not able to set quota on the filesystem.
Here's the mount options used:

# mount | grep u02
/dev/mapper/vg_app-lv_app on /u02 type ext4 (rw,acl,usrquota,grpquota)

Here's what I get when trying to enable quota:

# quotacheck -cug /u02
quotacheck: Cannot create new quotafile /u02/aquota.user.new: Permission denied
quotacheck: Cannot initialize IO on new quotafile: Permission denied
quotacheck: Cannot create new quotafile /u02/aquota.group.new: Permission denied
quotacheck: Cannot initialize IO on new quotafile: Permission denied

Here's the permissions on the /u02 directory:

# ls -ld /u02
drwxr-xr-x. 4 root root 4096 Feb 13 18:38 /u02
# getfacl /u02
getfacl: Removing leading '/' from absolute path names
# file: u02
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

dmesg | tail gives a hint that SELinux is using xattr on this filesystem:

EXT4-fs (dm-1): mounted filesystem with ordered data mode
SELinux: initialized (dev dm-1, type ext4), uses xattr

SELinux is set to enforcing. After setting SELinux to permissive mode, I was actually able to run the quotacheck command. But, I need to figure out a solution for this as SELinux has to be set to Enforcing as per the company policy.

There's no boolean for quota:

# getsebool -a | grep quota
#

SELinux context for the directory is like this:

# ls -ldZ /u02
drwxr-xr-x. root root system_u:object_r:file_t:s0      /u02

My guess is that this xattr thingy is causing the problem. Anyone has any idea what it is and how I can do my job without having to set SELinux to permissive mode? Thanks.

Bugzilla entry 703871 at bugzilla.redhat.com describes the problem. It recommends something like the following workaround before running the quotacheck:

# chcon ---reference=/var /u02

I'm a Red Hat employee and I just happened to see your post. If you are a Red Hat customer, you can pursue this issue further from the Red Hat customer portal (access.redhat.com). I hope this was helpful.

Thank you linuxcricket!!

I tried setting the SELinux context as that of /var, but I still got permission denied while trying to set quota.

# chcon --reference=/var /u02
# r ls
ls -ldZ /u02
drwxr-xr-x. root root system_u:object_r:var_t:s0       /u02
# quotacheck -cug /u02
quotacheck: Cannot rename new quotafile /u02/aquota.user.new to name /u02/aquota.user: Permission denied
quotacheck: Cannot rename new quotafile /u02/aquota.group.new to name /u02/aquota.group: Permission denied

The system is registered with RedHat. But, I need to go through a lot of approval processes to log a ticket with RedHat support.

Anyways, I dug deeper and went through AVC denials by doing this:

sealert -a /var/log/audit/audit.log

It showed me the solution as:

SELinux is preventing /sbin/quotacheck from write access on the directory /u02.

*****  Plugin restorecon (82.4 confidence) suggests  *************************

If you want to fix the label.
/u02 default label should be default_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /u02

*****  Plugin file (7.05 confidence) suggests  *******************************

If this is caused by a newly created file system.
Then you need to add labels to it.
Do
/sbin/restorecon -R -v /u02

*****  Plugin file (7.05 confidence) suggests  *******************************

If you think this is caused by a badly mislabeled machine.
Then you need to fully relabel.
Do
touch /.autorelabel; reboot

*****  Plugin catchall_labels (4.59 confidence) suggests  ********************

If you want to allow quotacheck to have write access on the u02 directory
Then you need to change the label on /u02
Do
# semanage fcontext -a -t FILE_TYPE '/u02'
where FILE_TYPE is one of the following: boot_t, root_t, tmp_t, usr_t, var_t, mail_spool_t, etc_t, mqueue_spool_t, var_spool_t, home_root_t.
Then execute:
restorecon -v '/u02'


*****  Plugin catchall (1.31 confidence) suggests  ***************************

If you believe that quotacheck should be allowed write access on the u02 directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep quotacheck /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

I executed this:

grep quotacheck /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp

And it worked. I could run the quotacheck command without any problem. Thanks for your time to post here.

# semanage fcontext -a -t var_t "/u02(/.*)?"
# restorecon -R -v /u02

This tells SELinux to label all content under /u02 as var_t and restorecon then resets the labels.

Since you are also going to use quota on this disk you could then execute the quota command without installing a custom policy.

But the real question is what kind of content is going to go in this directory, if it is going to be user directories, then this is the wrong label.

# semanage fcontext -a -e /home /v02
# restorecon -R -v /v02

Would then be the correct command.

Well this directory is going to be used by an application running on the server. I am monitoring the application now and it's actually working without any problem. I will check for the SELinux security context the application is using and will try changing the same for the /u02 directory. Thanks.

Ok, what you have allowed is just quota check to create a file in the default_t directory. default_t is the label we give to any directory in / that we don't know about. If another confined domain like apache tries to access content in this directory SELinux will block it. But if all the apps that use this directory are unconfined running as unconfined_t or initrc_t you should not have a problem.