On 5/29/05, Justin Conover justin.conover@gmail.com wrote:
Can't create a logical volume, have no problems doing it on another rawhide box. Plenty of space, I've done this ++++ times and for some reason this box is just causing a problem. "permission denied"
Could this be a dieing HD? The box has 4x36GB scsi drives in it, in Raid0/lvm config.
[root@trinity ~]# lvcreate -L2G -nLogVol08 VolGroup01 Logical volume "LogVol08" created [root@trinity ~]# mke2fs -j /dev/VolGroup01/LogVol08 mke2fs 1.37 (21-Mar-2005) Could not stat /dev/VolGroup01/LogVol08 --- Permission denied [root@trinity ~]# mkfs.ext3 -F -j /dev/VolGroup01/LogVol08 mke2fs 1.37 (21-Mar-2005) mkfs.ext3: Permission denied while trying to determine filesystem size # mkfs.ext3 -F -j /dev/mapper/VolGroup01-LogVol08 mke2fs 1.37 (21-Mar-2005) mkfs.ext3: Permission denied while trying to determine filesystem size ]# mkfs.ext3 -F -j /dev/mapper/VolGroup01-LogVol08 mke2fs 1.37 (21-Mar-2005) mkfs.ext3: Permission denied while trying to determine filesystem size [root@trinity ~]# mke2fs -f /dev/mapper/VolGroup01-LogVol08 mke2fs: bad fragment size - /dev/mapper/VolGroup01-LogVol08
[root@trinity ~]# id -Z root:system_r:unconfined_t [root@trinity ~]# ls -la /sbin/ | grep mkfs -rwxr-xr-x 1 root root 7192 May 3 23:30 mkfs -rwxr-xr-x 1 root root 15872 May 3 23:30 mkfs.cramfs -rwxr-xr-x 3 root root 35888 May 10 04:17 mkfs.ext2 -rwxr-xr-x 3 root root 35888 May 10 04:17 mkfs.ext3 -rwxr-xr-x 3 root root 30180 Apr 28 09:31 mkfs.msdos -rwxr-xr-x 3 root root 30180 Apr 28 09:31 mkfs.vfat [root@trinity ~]# lsmod | grep ext3 ext3 133193 8 jbd 61785 1 ext3
[root@trinity ~]# vgdisplay --- Volume group --- VG Name VolGroup01 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 12 VG Access read/write VG Status resizable MAX LV 0 Cur LV 9 Open LV 8 Max PV 0 Cur PV 1 Act PV 1 VG Size 101.28 GB PE Size 32.00 MB Total PE 3241 Alloc PE / Size 672 / 21.00 GB Free PE / Size 2569 / 80.28 GB VG UUID 8A535T-TOpJ-Fzkg-BREJ-TJE7-E3Lp-nChZOg
The differences on the box that work don't work are following,
Works (x86_64/rawhide) # rpm -qa | grep lvm lvm2-2.01.08-1.0 <----- WHY 2? lvm2-2.01.08-2.1 system-config-lvm-0.9.32-1.0 # rpm -qa | grep e2fsprogs e2fsprogs-devel-1.37-4 e2fsprogs-1.37-4.x86_64 e2fsprogs-1.37-4.i386
Doesn't work (x86/Rawhide) # rpm -qa | grep lvm lvm2-2.01.08-2.1 system-config-lvm-0.9.32-1.0 # rpm -qa | grep e2fsprogs e2fsprogs-devel-1.37-4 e2fsprogs-1.37-4 Both box's are in a soft raid/lvm config, Not sure why the i386 box defaulted to VolGroup01 but shouldn't matter in any case.
Well, it looks like the problem is between mkfs and selinux. The box that works is set to
# sestatus SELinux status: disabled
While the one that doesn't work is running selinux, so is this a bug, can anyone else mkfs on selinux=1 box's? I haven't run into this before and I know I have other box's running selinux that i've created new fs on.
Well, it looks like the problem is between mkfs and selinux. The box that works is set to
# sestatus SELinux status: disabled
While the one that doesn't work is running selinux, so is this a bug, can anyone else mkfs on selinux=1 box's? I haven't run into this before and I know I have other box's running selinux that i've created new fs on.
Forgot to include the fact I booted with selinux=0 and made the file system.
Justin Conover wrote:
Well, it looks like the problem is between mkfs and selinux. The box that works is set to
# sestatus SELinux status: disabled
While the one that doesn't work is running selinux, so is this a bug, can anyone else mkfs on selinux=1 box's? I haven't run into this before and I know I have other box's running selinux that i've created new fs on.
Forgot to include the fact I booted with selinux=0 and made the file system.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
You machine needs to be relabeled. If you boot as selinux=0 you will need to relabel when you want to run selinux again. Using enforcing=0 (setenforce 0) is a better option, since it maintains the file context. touch /.autorelabel reboot
Forgot to include the fact I booted with selinux=0 and made the file system.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
You machine needs to be relabeled. If you boot as selinux=0 you will need to relabel when you want to run selinux again. Using enforcing=0 (setenforce 0) is a better option, since it maintains the file context. touch /.autorelabel reboot
Right, but why did it not let me created a file system with selinux=1? I did a fresh install of fc4t3 on this box too, with the same results.
On Mon, 30 May 2005 08:30:49 CDT, Justin Conover said:
Right, but why did it not let me created a file system with selinux=1? I did a fresh install of fc4t3 on this box too, with the same results.
If you didn't already post the avc messages that mkfs generated (I've already deleted the first few msgs of this thread), could you do so? They'd be in /var/log/messages (if you have a default syslog config and aren't using auditd) or in /var/log/audit/audit.log if you have auditd running....
Although I'm suspecting the problem is, as others have mentioned, that your system needs to be relabeled, and that an improper label on something broke the mkfs.
On 5/30/05, Valdis.Kletnieks@vt.edu Valdis.Kletnieks@vt.edu wrote:
On Mon, 30 May 2005 08:30:49 CDT, Justin Conover said:
Right, but why did it not let me created a file system with selinux=1? I did a fresh install of fc4t3 on this box too, with the same results.
If you didn't already post the avc messages that mkfs generated (I've already deleted the first few msgs of this thread), could you do so? They'd be in /var/log/messages (if you have a default syslog config and aren't using auditd) or in /var/log/audit/audit.log if you have auditd running....
Although I'm suspecting the problem is, as others have mentioned, that your system needs to be relabeled, and that an improper label on something broke the mkfs.
Ok, still have problems, set "enforcing=0" and relabeled and here is all the bits.
# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 19 Policy from config file: targeted
<SNIP>
# mkdir /lvm_test_dir
# vgdisplay --- Volume group --- VG Name VolGroup00 System ID Format lvm2 Metadata Areas 4 Metadata Sequence No 11 VG Access read/write VG Status resizable MAX LV 0 Cur LV 9 Open LV 9 Max PV 0 Cur PV 4 Act PV 4 VG Size 135.28 GB PE Size 32.00 MB Total PE 4329 Alloc PE / Size 1408 / 44.00 GB Free PE / Size 2921 / 91.28 GB VG UUID TxPt55-hDYK-lJmC-Aohb-LbGe-glnr-7046hW
# lvcreate -L2G -nLogVol10 VolGroup00 Logical volume "LogVol10" created
# mkfs.ext3 /dev/VolGroup00/LogVol10 mke2fs 1.37 (21-Mar-2005) Could not stat /dev/VolGroup00/LogVol10 --- Permission denied
# grep mkfs audit/audit.log type=SYSCALL msg=audit(1117397418.851:206892): arch=40000003 syscall=195 success=no exit=-13 a0=bf8aebdf a1=bf8605d8 a2=838ff4 a3=0 items=1 pid=2247 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="mkfs.ext3" exe="/sbin/mkfs.ext3" type=AVC msg=audit(1117397418.851:206892): avc: denied { getattr } for pid=2247 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t tclass=file type=SYSCALL msg=audit(1117397783.921:261196): arch=40000003 syscall=195 success=no exit=-13 a0=bf856bdf a1=bf7eed58 a2=bc7ff4 a3=0 items=1 pid=2308 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="mkfs.ext3" exe="/sbin/mkfs.ext3" type=AVC msg=audit(1117397783.921:261196): avc: denied { getattr } for pid=2308 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t tclass=file type=SYSCALL msg=audit(1117470602.109:1094349): arch=40000003 syscall=195 success=no exit=-13 a0=bf87fc52 a1=bf87e7a8 a2=a1dff4 a3=0 items=1 pid=4009 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="mkfs.ext3" exe="/sbin/mkfs.ext3" type=AVC msg=audit(1117470602.109:1094349): avc: denied { getattr } for pid=4009 comm="mkfs.ext3" name=VolGroup00-LogVol10 dev=tmpfs ino=56551 scontext=root:system_r:fsadm_t tcontext=root:object_r:device_t tclass=blk_file
On Mon, 30 May 2005 11:33:28 CDT, Justin Conover said:
OK, with this info, I'm convinced that (a) you're not nuts, (b) your system is labelled the way we told it to be labelled, and (c) we told it the wrong thing. ;)
# lvcreate -L2G -nLogVol10 VolGroup00 Logical volume "LogVol10" created
# mkfs.ext3 /dev/VolGroup00/LogVol10 mke2fs 1.37 (21-Mar-2005) Could not stat /dev/VolGroup00/LogVol10 --- Permission denied
Could you do a 'ls -lZ /dev/VolGroup00'? I'd like to verify that lvcreate left LogVol10 labelled correctly - although I suspect that it got left what lvm thought it should be, and the policy wanted something else....
# grep mkfs audit/audit.log type=AVC msg=audit(1117397418.851:206892): avc: denied { getattr } for pid=2247 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t tclass=file
This one looks like an attempt to scribble on a file called fedora.img - can you do a 'grep dm-7 /proc/mounts' and then do a 'find /filesys -name fedora.img -ls' and perhaps ls -lZ the file?
(Anybody recognize this one? I'm guessing it's a mkinitrd and dm-7 is /tmp...)
type=AVC msg=audit(1117397783.921:261196): avc: denied { getattr } for pid=2308 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t tclass=file
Another one of the same...
type=AVC msg=audit(1117470602.109:1094349): avc: denied { getattr } for pid=4009 comm="mkfs.ext3" name=VolGroup00-LogVol10 dev=tmpfs ino=56551 scontext=root:system_r:fsadm_t tcontext=root:object_r:device_t tclass=blk_file
Here's the one that's causing yu the pain, and yes, it's borked up, and no, it doesn't apear to be your fault - the system (lvm in particular) could be doing a better job of labelling...
Hmm.. I'll place bets that if you do a 'mkfs.ext3 /dev/dm-N' that it will work just fine, as they're created as fixed_disk_device_t. At least on my box, the symlink entries in /dev/VolGroup00 are being created as 'device_t' - and the targets in /dev/mapper are tmpfs_t (quite borked) of all things.
Fortuitously, we have this in fsadm.te:
# for /dev/shm allow fsadm_t tmpfs_t:dir { getattr search }; allow fsadm_t tmpfs_t:file { read write };
which seems to be likely to allow the access for all the wrong reasons.
I'm thinking the symlinks in /dev/VolGroup00 should be fixed_disk_device_t rather than device_t - do others concur? And I'm suspecting the stuff in /dev/mapper needs to be set to fixed_disk_device_t as well - that way the /dev/dm-* and /dev/mapper/* entries for the same device are the same type (a nasty security exposure otherwise...)
How do we get lvm to DTRT here? We can add a line to file_contexts/program/lvm.fc to fix the /dev/mapper entries:
--- file_contexts/program/lvm.fc.dist 2005-05-20 14:53:12.000000000 -0400 +++ file_contexts/program/lvm.fc 2005-05-30 13:10:03.000000000 -0400 @@ -12,6 +12,7 @@ /etc/lvm/lock(/.*)? system_u:object_r:lvm_lock_t /var/lock/lvm(/.*)? system_u:object_r:lvm_lock_t /dev/lvm -c system_u:object_r:fixed_disk_device_t +/dev/mapper/.* -c system_u:object_r:fixed_disk_device_t /dev/mapper/control -c system_u:object_r:lvm_control_t /lib/lvm-10/.* -- system_u:object_r:lvm_exec_t /lib/lvm-200/.* -- system_u:object_r:lvm_exec_t
At least on my system, that leaves the /dev/mapper/* entries more sane....
(Justin - the above patch won't fly unless you have policy-sources installed. If you're feeling brave, crazy, and adventurous, make a similar change to /etc/selinux/strict/contexts/files/file_contexts, and then do a 'restorecon -v -R /dev' - make sure to save a backup of file_contexts first.. ;)
After that, you *should* be able to do a 'mkfs.ext3 /dev/mapper/VolGroup00-LogVol10'
But that still leaves the symlinks in /dev/VolGroup00 set wrong. Do we need to add a 'follow symlink' in lvm.te? We can't fix this one in the file_contexts, because that dirname is essentially user-selected - on my system it's /dev/rootvg (guess who comes from an AIX background? ;)
Or is there other borkedness here, and that it's the /dev/mapper/* that's causing Justin's indigestion, but we're reporting the context of the symlink rather than the target that's actually failing? (Anybody want to devise a quick test case for this one?)
On 5/30/05, Valdis.Kletnieks@vt.edu Valdis.Kletnieks@vt.edu wrote:
On Mon, 30 May 2005 11:33:28 CDT, Justin Conover said:
OK, with this info, I'm convinced that (a) you're not nuts, (b) your system is labelled the way we told it to be labelled, and (c) we told it the wrong thing. ;)
Not so fast on "A" :D
# lvcreate -L2G -nLogVol10 VolGroup00 Logical volume "LogVol10" created
# mkfs.ext3 /dev/VolGroup00/LogVol10 mke2fs 1.37 (21-Mar-2005) Could not stat /dev/VolGroup00/LogVol10 --- Permission denied
Could you do a 'ls -lZ /dev/VolGroup00'? I'd like to verify that lvcreate left LogVol10 labelled correctly - although I suspect that it got left what lvm thought it should be, and the policy wanted something else....
# ls -lZ /dev/VolGroup00 lrwxrwxrwx root root system_u:object_r:device_t LogVol00 -> /dev/mapper/VolGroup00-LogVol00 lrwxrwxrwx root root system_u:object_r:device_t LogVol01 -> /dev/mapper/VolGroup00-LogVol01 lrwxrwxrwx root root system_u:object_r:device_t LogVol02 -> /dev/mapper/VolGroup00-LogVol02 lrwxrwxrwx root root system_u:object_r:device_t LogVol03 -> /dev/mapper/VolGroup00-LogVol03 lrwxrwxrwx root root system_u:object_r:device_t LogVol04 -> /dev/mapper/VolGroup00-LogVol04 lrwxrwxrwx root root system_u:object_r:device_t LogVol05 -> /dev/mapper/VolGroup00-LogVol05 lrwxrwxrwx root root system_u:object_r:device_t LogVol06 -> /dev/mapper/VolGroup00-LogVol06 lrwxrwxrwx root root system_u:object_r:device_t LogVol07 -> /dev/mapper/VolGroup00-LogVol07 lrwxrwxrwx root root system_u:object_r:device_t LogVol08 -> /dev/mapper/VolGroup00-LogVol08 lrwxrwxrwx root root system_u:object_r:device_t LogVol10 -> /dev/mapper/VolGroup00-LogVol10
# grep mkfs audit/audit.log type=AVC msg=audit(1117397418.851:206892): avc: denied { getattr } for pid=2247 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t tclass=file
This one looks like an attempt to scribble on a file called fedora.img - can you do a 'grep dm-7 /proc/mounts' and then do a 'find /filesys -name fedora.img -ls' and perhaps ls -lZ the file?
fedora.img is part of some Xen stuff I was doing, which initially started this whole thing of mkfs not working.
(Anybody recognize this one? I'm guessing it's a mkinitrd and dm-7 is /tmp...)
type=AVC msg=audit(1117397783.921:261196): avc: denied { getattr } for pid=2308 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t tclass=file
Another one of the same...
type=AVC msg=audit(1117470602.109:1094349): avc: denied { getattr } for pid=4009 comm="mkfs.ext3" name=VolGroup00-LogVol10 dev=tmpfs ino=56551 scontext=root:system_r:fsadm_t tcontext=root:object_r:device_t tclass=blk_file
Here's the one that's causing yu the pain, and yes, it's borked up, and no, it doesn't apear to be your fault - the system (lvm in particular) could be doing a better job of labelling...
Hmm.. I'll place bets that if you do a 'mkfs.ext3 /dev/dm-N' that it will work just fine, as they're created as fixed_disk_device_t. At least on my box, the symlink entries in /dev/VolGroup00 are being created as 'device_t' - and the targets in /dev/mapper are tmpfs_t (quite borked) of all things.
Fortuitously, we have this in fsadm.te:
# for /dev/shm allow fsadm_t tmpfs_t:dir { getattr search }; allow fsadm_t tmpfs_t:file { read write };
which seems to be likely to allow the access for all the wrong reasons.
I'm thinking the symlinks in /dev/VolGroup00 should be fixed_disk_device_t rather than device_t - do others concur? And I'm suspecting the stuff in /dev/mapper needs to be set to fixed_disk_device_t as well - that way the /dev/dm-* and /dev/mapper/* entries for the same device are the same type (a nasty security exposure otherwise...)
How do we get lvm to DTRT here? We can add a line to file_contexts/program/lvm.fc to fix the /dev/mapper entries:
--- file_contexts/program/lvm.fc.dist 2005-05-20 14:53:12.000000000 -0400 +++ file_contexts/program/lvm.fc 2005-05-30 13:10:03.000000000 -0400 @@ -12,6 +12,7 @@ /etc/lvm/lock(/.*)? system_u:object_r:lvm_lock_t /var/lock/lvm(/.*)? system_u:object_r:lvm_lock_t /dev/lvm -c system_u:object_r:fixed_disk_device_t +/dev/mapper/.* -c system_u:object_r:fixed_disk_device_t /dev/mapper/control -c system_u:object_r:lvm_control_t /lib/lvm-10/.* -- system_u:object_r:lvm_exec_t /lib/lvm-200/.* -- system_u:object_r:lvm_exec_t
At least on my system, that leaves the /dev/mapper/* entries more sane....
(Justin - the above patch won't fly unless you have policy-sources installed. If you're feeling brave, crazy, and adventurous, make a similar change to /etc/selinux/strict/contexts/files/file_contexts, and then do a 'restorecon -v -R /dev' - make sure to save a backup of file_contexts first.. ;)
After that, you *should* be able to do a 'mkfs.ext3 /dev/mapper/VolGroup00-LogVol10'
But that still leaves the symlinks in /dev/VolGroup00 set wrong. Do we need to add a 'follow symlink' in lvm.te? We can't fix this one in the file_contexts, because that dirname is essentially user-selected - on my system it's /dev/rootvg (guess who comes from an AIX background? ;)
Or is there other borkedness here, and that it's the /dev/mapper/* that's causing Justin's indigestion, but we're reporting the context of the symlink rather than the target that's actually failing? (Anybody want to devise a quick test case for this one?)
I have no problem doing some of this if someone else chimes in too, it's a new box I'm working on so there is nothing that a new install wont cure for a borked system.
On Mon, 30 May 2005 15:02:44 CDT, Justin Conover said:
Not so fast on "A" :D
Well, the *current* evidence indicates you're not off the deep end on this specific issue, anyhow.. ;)
fedora.img is part of some Xen stuff I was doing, which initially started this whole thing of mkfs not working.
We probably need to come back sometime and address the issues of mkfs on a file intended for loopback-mount - that's a separate borkage..
--- file_contexts/program/lvm.fc.dist 2005-05-20 14:53:12.000000000 -0400 +++ file_contexts/program/lvm.fc 2005-05-30 13:10:03.000000000 -0400 @@ -12,6 +12,7 @@ /etc/lvm/lock(/.*)? system_u:object_r:lvm_lock_t /var/lock/lvm(/.*)? system_u:object_r:lvm_lock_t /dev/lvm -c system_u:object_r:fixed_disk_device_t +/dev/mapper/.* -c system_u:object_r:fixed_disk_device_t /dev/mapper/control -c system_u:object_r:lvm_control_t /lib/lvm-10/.* -- system_u:object_r:lvm_exec_t /lib/lvm-200/.* -- system_u:object_r:lvm_exec_t
At least on my system, that leaves the /dev/mapper/* entries more sane....
(Justin - the above patch won't fly unless you have policy-sources installe
d.
If you're feeling brave, crazy, and adventurous, make a similar change to /etc/selinux/strict/contexts/files/file_contexts, and then do a 'restorecon -v -R /dev' - make sure to save a backup of file_contexts first
.. ;)
After that, you *should* be able to do a 'mkfs.ext3 /dev/mapper/VolGroup00-LogVol10'
I have no problem doing some of this if someone else chimes in too, it's a new box I'm working on so there is nothing that a new install wont cure for a borked system.
If you can try the file_contexts tweak I mentioned, and verify that you can or can't do a mkfs on /dev/dm-N and /dev/mapper/VolGrouo00-LogVol10, that would help some (and at least give you a known-good workaround while we come up with a proper fix. Even if I've recommended something stupid, a re-install will clear it. ;)
/dev/VolGroup00/LogVol?? will require some other fix which I'd speculate on, but I have to be at a barbeque in 30 mins.. ;)
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Justin Conover -
Valdis.Kletnieks＠vt.edu