mkfs.ext3: Permission denied while trying to determine filesystem size

[Justin Conover]

On 5/30/05, Valdis.Kletnieks at vt.edu <Valdis.Kletnieks at 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.