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 Author): Re: First successful bootup Jörgen Sigvardsson
Previous Article (by Author): Re: First successful bootup Jörgen Sigvardsson
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 Author): Re: First successful bootup Jörgen Sigvardsson
Previous Article (by Author): Re: First successful bootup Jörgen Sigvardsson
Top of Thread: UML+RSBAC = TRUE...? Jörgen Sigvardsson
Articles sorted by: [Date]
[Author]
[Subject]