[rsbac] initrd again ?

[Andrea Pasquinucci]

Hi, I think I have been hit again by this initrd thing. Has it been solved?
Any way out different from booting in softmode ? Or does the trick suggested 
by Amon work with no problem/side effect ?

My log is


kernel: rsbac_adf_request(): request MOUNT, pid 173, ppid 1, prog_name linuxrc, uid 0, target_type DIR, tid Device 03:01 Inode 96201 Path /initrd, attr none, value 0, result NOT_GRANTED (Softmode) by RC
kernel: rsbac_adf_request(): request MOUNT, pid 173, ppid 1, prog_name linuxrc, uid 0, target_type DIR, tid Device 01:00 Inode 2 Path /, attr none, value 0, result NOT_GRANTED (Softmode) by RC
kernel: rsbac_free_dat_dentry(): freeing dat dir dentries
kernel: rsbac_get_attr(): auto-mounting device 00:03
kernel: rsbac_adf_request(): request UMOUNT, pid 173, ppid 1, prog_name linuxrc, uid 0, target_type DIR, tid Device 00:03 Inode 1 Path /, attr none, value 0, result NOT_GRANTED (Softmode) by RC
kernel: rsbac_adf_request(): request UMOUNT, pid 173, ppid 1, prog_name linuxrc, uid 0, target_type DEV, tid block 00:03, attr none, value 0, result NOT_GRANTED (Softmode) by RC


Thanks Andrea

PS. I am not sure Amon trick works with the first error message though.


On Donnerstag, 22. Juli 2004 16:52, Rob See wrote:
> On Jul 22, 2004, at 10:36 AM, Amon Ott wrote:
> >>>
> >> Really once the rsbac_init happens,  linuxrc just needs to be able to
> >> umount a couple of things (/proc is one of them), so that the normal
> >> init scripts can mount it in the right place. I don't believe that I
> >> can call other scripts (I'm using nash, the redhat initrd shell, also 
> >> I
> >> don't want to have to switch to secoff to create the initrd) Before 
> >> the
> >> boot role support was added, what role would this script have run in ?
> >
> > It must have been root's role (usuall 2) or 0. I cannot tell for sure.
> 
> Do you have any other suggestions for a fix for this?

A quick and dirty workaround is to start in softmode and switch it off 
right after the umount stuff.

You can try to set a different rc_type_fd on your final root dir. Then you 
can grant role 0 to umount FD type 0, because type 0 is only available in 
the initrd. Once that has been umounted, all type 0 FD objects are gone 
from normal filesystem, so the right does not harm you.

Just be careful to avoid dirty multimount tricks on a filesystem, which 
break the inheritance, if you have no explicit type set on the root dir of 
that filesystem. If inheritance is broken, the default type value at the 
mount point and below is 0. This might also hit you with some kernel 
special filesystems like socketfs or pipefs, but umount has little meaning 
there.

Argggh, initrd hits again. It might be useful in some cases, but it loves 
to create trouble. :(

I will try to come up with a general solution, which does not open any 
security holes.

Amon.