Re: UML+RSBAC = TRUE...?


From: Jörgen Sigvardsson <jorgen.sigvardsson@kau.se>
Subject: Re: UML+RSBAC = TRUE...?
Date: Mon, 12 Feb 2001 14:44:53 +0100

Next Article (by Subject): UML-stuff Jörgen Sigvardsson
Previous Article (by Subject): Re: UML+RSBAC = TRUE...? Amon Ott
Top of Thread: UML+RSBAC = TRUE...? Jörgen Sigvardsson
Articles sorted by: [Date] [Author] [Subject]


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 12 February 2001 09:11, you wrote:
> > rsbac_init_rc(): Initializing RSBAC: RC subsystem
> > rsbac_init_rc(): roles could not be sufficiently read, error
> > RSBAC_ENOTFOUND, default role entries might be used!
> > - ----8<----------
> >
> > And then hell breaks loose. (to put it mildly)
>
> What exactly breaks loose here? As hell seems to happen during RC init, you
> could try kernel parameter 'rsbac_debug_ds_rc'.
I should have given some more information I guess. What happens is that it 
fails to do stuff on proc (00:05 I think and devfs 00:some other minor). Then 
after a couple of errors related to those devices, a kernel panic occurs, and 
the system hangs. I have figured out that /etc/somewhere/rcS (startup 
scripts) tries to unmount the root directory for some reason (!?). This 
happened when I used the "small debian root fs" that can be downloaded from 
the UML home page. Then I tried another root file system for another 
distribution (root_fs_tomrtbt_1.7.205.bz2 whatever tomrtbt is). Then I get to 
the login prompt at least. When I try to login it just hangs.
>
> > I'm currently investigating it, but if you have a hint of what may be
> > wrong, I'd gladly accept the hint. I read in the docs that after 1.0.9 no
> > administration prior to rsbac boot up is not needed since it would
> > automagically setup ACI.
>
> All necessary setup happens during init, when stuff is loaded. After that,
> nothing is added automatically any more.
>
> My usual procedure, if I get an early crash:
>
> Start with a maint kernel without proc, module support and write-to-disk
> and see if that one comes up.
>
> Next, turn on proc, then write-to-disk, then the modules. From the first
> version that crashes try to organize a log for me with kernel parameters
> 'debug' and rsbac_debug_ds. If a crash happens during module init,
> rsbac_debug_<modname> should also be tried.
>
> After that, turn on the rest of the features. Most of them are harmless,
> because they change internal behaviour.
Ok. Many thanks for the advice, I'll try it ASAP. I am however starting from 
scratch again using the 2.4.1 series (UML and RSBAC) and 1.1.0 version of 
RSBAC. I tried the latest RSBAC 1.1.1 prerelease at first.
However, I'll probably won't have any updates until tomorrow since this 
monday seems to be filled with meetings. 


As a side note, UML is quite handy. During execution it is possible to send 
the signal SIGUSR1 to the tracing thread and voilà - an xterm stuffed with 
delicious gdb shows up. This could really speed up kernel development when it 
comes down to obscure bugs. I really hope the UML architecture becomes a part 
of the mainstream kernel. This would make things easier to combine RSBAC and 
UML. Right now I have to manually edit syscall tables every single time when 
I repatch, which is quite annoying. 

- -- 
Jörgen Sigvardsson, B. Sc.
Lecturer, Computer Science Dept. Karlstad University
Tel: +46-(0)54-700 1786
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6h+jcJtcD8rikkmwRApfEAJ9xE5BVFagBgMgyIw2lKTkVWfZXSwCfaTKp
Kfjcmm2suLB/lchZ9EUwWL4=
=L02U
-----END PGP SIGNATURE-----
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Next Article (by Subject): UML-stuff Jörgen Sigvardsson
Previous Article (by Subject): Re: UML+RSBAC = TRUE...? Amon Ott
Top of Thread: UML+RSBAC = TRUE...? Jörgen Sigvardsson
Articles sorted by: [Date] [Author] [Subject]


Go to Compuniverse LWGate Home Page.