From: Amon Ott <ao@rsbac.org>
Subject: Re: Re[4]: RSBAC v1.1.1 problem
Date: Tue, 3 Apr 2001 14:09:29 +0200
Next Article (by Subject): Re[6]: RSBAC v1.1.1 problem Keith Matthews
Previous Article (by Subject): Re[4]: RSBAC v1.1.1 problem Keith Matthews
Top of Thread: Re[4]: RSBAC v1.1.1 problem Keith Matthews
Articles sorted by: [Date]
[Author]
[Subject]
On Die, 03 Apr 2001 Keith Matthews wrote:
> On Thu, 29 Mar 2001 11:45:46 +0200 Amon Ott <Amon Ott <ao@rsbac.org>> wrote:
>
> > On Mit, 28 Mr 2001 Keith Matthews wrote:
>
> > Did you install the dialog tool? This is the only reason I can find. rsbac_menu
> > does not do anything before displaying the main menu.
> >
>
> Not I did not. On checking I had difficulty finding anything significant
> about dialog in the documentation. Perhaps a documentation change is also
> required.
Well, they are called the 'dialog menu tools'. In my tool tree, the menues
already check for dialog and give a clear message, if dialog is missing. You
will see this in 1.1.2.
> Having got that bit to run I still cannot deal with things. Strange
> message are in the logs, for example it is claiming to initialise itself
> as v 1.1.0, (I have rechecked that it was the 1.1.1 tarball) and most of
> the modules are reporting that they cannot find files (e.e. Dev ACI could
> not be read).
This is really weird. I never had that. Did you possibly extract the 1.1.1
tarball over an existing RSBAC 1.1.0 kernel without a make dep afterwards?
Certainly not.
The reports are OK - ENOTFOUND just means that you never changed anything in
this list, so it never got written. This at least should be in instadm.htm,
section 'First Boot'.
> Also ifconfig on eth0 is failing with nothing in the log, but I suspect
> this to be a permissions problem. pcmcia is now running (apparantly OK).
If RSBAC works OK with default settings, everything that is denied must be
logged. If not, something is wrong.
> I also noticed that the secoff cannot get to objects to change access
> unless they are below his own home directory, perhaps this is a
> consequence of the initialisation problems.
In default settings, secoff gets full permission to everything, except clear
sysadmin jobs, e.g. mounting etc.
Which module(s) deny the desired access?
Also, you could try to reboot a non-RSBAC kernel, rm -r /rsbac and reboot RSBAC
with rsbac_auth_enable_login. This must restore the default settings. If it
still fails, I would have to get my hands on your PC.
Amon.
-
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): Re[6]: RSBAC v1.1.1 problem Keith Matthews
Previous Article (by Subject): Re[4]: RSBAC v1.1.1 problem Keith Matthews
Top of Thread: Re[4]: RSBAC v1.1.1 problem Keith Matthews
Articles sorted by: [Date]
[Author]
[Subject]