Bug 634179

How reproducible:


Steps to Reproduce:
1. Create an lvm partition
pvcreate /dev/sda5
vgcreate TEST /dev/sda5
lvcreate -n test -L50M TEST

2. Partition filesystem.
mkfs.ext3 /dev/mapper/TEST-test
mount -o usrquota /dev/mapper/TEST-test /mnt

3. Add a user.
useradd test

4. Enable quotas 
quotacheck -cugvm /mnt
quotaon /mnt
mkfir /mnt/test
chmod 777 /mnt/test

5. Add some quotas
edquota -u test

6. Become user, do some work

7. Restart the station

8. edquota -u test
Check the status of inodes or used size

9. Redo some work as user on the defined partition.

10. edquota -u test
Check the status of inodes or used size
Nothing have changed since point 8.

11. then you have to do quotaon /mnt

Actual results:

Quota doesn't work at all.

Expected results:

User should be limited by the specifications made at poit 10.

Additional info:

The quotaon is executed by /etc/rc.d/rc.sysinit belonging to initscripts package.

(In reply to comment #0)
> Description of problem:
> When you set quota over LVM, quotaon is not started properly due to the fact
> that logical volume management is started after quota in /etc/rc.sysinit

quotaon is done after mount & fsck, which is well after LVM.

What does '/sbin/quotaon -avug' say when run from single user mode?

Dear Bill,

Thanks for your reply.

1] This is the output of what you have requested : 
[root@rhce1 ~]# init 1
[root@rhce1 ~]# runlevel
5 1
[root@rhce1 ~]# /sbin/quotaon -avug
/dev/mapper/vgraid-lvraid [/raid]: group quotas turned on
/dev/mapper/vgraid-lvraid [/raid]: user quotas turned on

2] The above result is in ad-equation of what I wrote in my previous posts.
I mean that quota is not activated during boot sequence even if it is included in /etc/rc.sysinit.

3] You are right this is not due to the fact that LVM is started after quota.
   So I was wrong in my assumption. My apologies for that.

4] This is the content /var/log/boot.log :

Setting up Logical Volume Management:   1 logical volume(s) in volume group "vgraid" now active
  2 logical volume(s) in volume group "VolGroup" now active
                                                           [  OK  ]
Checking filesystems
/dev/mapper/VolGroup-lv_root: clean, 137181/430784 files, 1068266/1720320 blocks
/dev/vda1: clean, 45/128016 files, 85869/512000 blocks
/dev/mapper/vgraid-lvraid: clean, 14/128 files, 53/1024 blocks (check in 4 mounts)
                                                           [  OK  ]
Remounting root filesystem in read-write mode:             [  OK  ]
Mounting local filesystems:                                [  OK  ]
Enabling local filesystem quotas:                          [FAILED]
Enabling /etc/fstab swaps:                                 [  OK  ]
Entering non-interactive startup
Starting monitoring for VG VolGroup:   2 logical volume(s) in volume group "VolGroup" monitored
                                                           [  OK  ]
Starting monitoring for VG vgraid:   1 logical volume(s) in volume group "vgraid" monitored
                                                           [  OK  ]

5] BTW, my test config is indeed quota on LVM on raid 1.

w.r.t. testing from single-user mode, can you try it from a reboot with 'linux single' on the command line?

Created attachment 447568 [details]
screenshot of the VM in single mode where i have the problem

Dear Bill,

Does it exist a log file for quota ?

BR
Frederic

That's weird. No, there's not a log

Can you do: 'strace -fo -s 999 /tmp/quota.log quotaon -avug' and attach that file?

Created attachment 447687 [details]
Correct screenshot

Dear Bill,

I used the indeed the following command : /usr/bin/strace -f -s 999 -o /tmp/quota.log /sbin/quotaon -avug
And the output of that command will be enclosed to that ticket asap.

BR
Frederic

Created attachment 447694 [details]
Output of what have been requested

Dear Bill,

I have made some progress and think that is maybe related to SELinux.
Please have a look at the new enclosed file - see below -

Created attachment 447696 [details]
SELinux related

Dear Bill,

It seems that when quotaon is lauched in single mode it fails due to SELinux rules... - see attachment 447696 [details] here above -
But when we are in runlevel 5 it works with SELinux enabled.
Maybe my conclusion is wrong or misinterpreted but it is what I can see - see new attachment below -.

Please could you check it on your own VM ?
Do I have to set a particular SELinux boolean on ?

BR
Frederic

Created attachment 447700 [details]
Same exercice in runlevel 5

Can you attach the output of 'ausearch -m avc' (or dmesg, if the AVCs are listed there.)

Dear Bill,

Well, nothing relevant with 'ausearch  -m avc' unfortunatly :(
I have attached files associated to each command

Have you try to reproduce it on a Virtual Machine ?

I also have done an sosreport file. - attached with this ticket -

BR
Frederic ;)

Created attachment 447801 [details]
dmesg output

Created attachment 447802 [details]
AVC output

Created attachment 447803 [details]
SOSReport

Frederic,

Execute 

semodule -DB
Then try quota

See if this generates avcs.

semodule -B 

Will turn the dontaudit messages back on.

Dear Daniel,

This is the result of what you requested :

[root@rhce1 /]# semodule -DB
[root@rhce1 /]# echo $?
0
[root@rhce1 /]# quotaon -avug
[root@rhce1 /]# echo $?
2
[root@rhce1 /]# semodule -R

BR
Frederic

*** Bug 635623 has been marked as a duplicate of this bug. ***

Frederic I need the AVC report

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I'm observing this on RHEL6.0 from media and after updates.

with selinux permissive, quotas are enabled on boot.
With selinux enforcing, quotas fail to start on boot, yielding this message in /var/log/messages.

quotas start without error when run as root login immediately after boot.

On an EC2 AMI

Apr  5 17:02:49 ip-10-242-85-153 kernel: VFS: Disk quotas dquot_6.5.2
Apr  5 17:02:49 ip-10-242-85-153 kernel: dracut: Remounting /dev/disk/by-label/_\x2f with -o usrjquota=aquota.user,jqfmt=vfsv0,ro
Apr  5 17:02:49 ip-10-242-85-153 kernel: type=1400 audit(1302037326.962:4): avc:  denied  { quotaon } for  pid=561 comm="quotaon" name="aquota.user" dev=xvda1 ino=702 scontext=system_u:system_r:quota_t:s0 tcontext=unconfined_u:object_r:root_t:s0 tclass=file


On an HP blade:

Apr  5 21:00:19 blade14 dbus: avc:  netlink poll: error 4
Apr  5 21:07:26 blade14 kernel: type=1400 audit(1302037638.639:4): avc:  denied  { quotaon } for  pid=1247 comm="quotaon" name="aquota.user" dev=sda4 ino=13 scontext=system_u:system_r:quota_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file
Apr  5 21:07:28 blade14 dbus: avc:  netlink poll: error 4

In neither case was any filesystem on the host using LVM directly.  I can't say what's behind the EC2 virt host.

The AVC that I have been sent recently indicate that /aquota.user and
/var/lib/aquota.user were labeled incorrectly,  How do those files get created?

Looks like these files should get created by quota on start, if they did not exist already.  I believe this is a labeling problem.  If you remove the files does quota create them with the right label?   Did you run the quotaon service by hand and then later run it in a service?

(In reply to comment #30)
> The AVC that I have been sent recently indicate that /aquota.user and
> /var/lib/aquota.user were labeled incorrectly,  How do those files get created?

The quota files are created by quotacheck tool. If they exists, they will be replaced by new quota files by rename(2) to assure atomicity. The name of quota files depends on quota format version and on name space (users, groups) they meassure: {,a}quota.{user,group}. Also if journaled quota files are used, the name can be any arbitrary file name specified by mount options usrjquota and grpjquota.

Who should specify label for those files? quotacheck binary or SELinux policy based on context of quotacheck binary?

In one of the two cases a user defined selinux policy overrides the default so that restorecon no longer sets the correct type on the aquota.user file.  This case is being addressed by correcting the user policy.

Petr's question remains:  Who is responsible for setting the label for those files and when?

I would say we need to have the proper policy in place for quotacheck to create the files with the right labels.

Miroslav looks like we need

optional_policy(`
	quota_run(unconfined_t, unconfined_r)
')

In F13,F14, F15, RHEL5 RHEL6.


Mark could you install build and install the following policy to make sure it works correctly.

==========================  cut int myquota.te ==================================
policy_module(myquota, 1,0)
gen_require(`
      type unconfined_t;
      role unconfined_r;
')

quota_run(unconfined_t, unconfined_r)
========================================================================

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

Then remove /aquota.user
run quotacheck

And make sure /aquota.user gets created with the correct label, and no avc's are generated.

Before policy change:

[root@ip-10-110-250-122 ~]# mount -o remount,defaults,usrjquota=aquota.user,jqfmt=vfsv0 /
[root@ip-10-110-250-122 ~]# quotacheck -cmuf /[root@ip-10-110-250-122 ~]# ls -Z /aquota.user 
-rw-------. root root unconfined_u:object_r:etc_runtime_t:s0 /aquota.user
[root@ip-10-110-250-122 ~]# rm /aquota.user 
rm: remove regular file `/aquota.user'? y


[root@ip-10-110-250-122 ~]# vi myquota.te
[root@ip-10-110-250-122 ~]# make -f /usr/share/selinux/devel/Makefile
Compiling targeted myquota module
/usr/bin/checkmodule:  loading policy configuration from tmp/myquota.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 10) to tmp/myquota.mod
Creating targeted myquota.pp policy package
rm tmp/myquota.mod tmp/myquota.mod.fc
[root@ip-10-110-250-122 ~]# semodule -i myquota.pp
[root@ip-10-110-250-122 ~]# ls /
bin   cgroup  etc   lib    lost+found  misc  net  proc  sbin     srv  tmp  var
boot  dev     home  lib64  media       mnt   opt  root  selinux  sys  usr

After policy change:

[root@ip-10-110-250-122 ~]# quotacheck -cmuf /
[root@ip-10-110-250-122 ~]# ls -Z /aquota.user 
-rw-------. root root unconfined_u:object_r:quota_db_t:s0 /aquota.user

Miroslav lets add this, I think it is low risk.  We need it in RHEL6 also.

Fixed in selinux-policy-3.7.19-107.fc13

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping