Re: Upcoming 1.1.1 changes

From: "John Huttley" <John@mwk.co.nz>
Subject: Re: Upcoming 1.1.1 changes
Date: Fri, 5 Jan 2001 10:20:32 +1300

Next Article (by Date): Re: patch-2.4.0-prerelease-v1.1.0 is uploaded "John Huttley"
Previous Article (by Date): new r-tools in /pre dir Amon Ott
Top of Thread: Upcoming 1.1.1 changes Amon Ott
Next in Thread: Re: Upcoming 1.1.1 changes Amon Ott
Articles sorted by: [Date] [Author] [Subject]

----- Original Message -----
From: Amon Ott <ao@rsbac.org>
To: RSBAC List <rsbac@compuniverse.de>
Sent: Friday, 5 January 2001 01:09
Subject: Upcoming 1.1.1 changes

> Hi!
>
> 1.1.1-pre1 is getting into shape now.
>
> Other wishes?
>

Yes.

The semantics of the FF module are confusing.

It ought to be one of the simplest models, but I cant figure it out.

Firstly there is the naming of attributes as "only".

This implies exclusivity. It is logically impossible to have two attributes named
"only" active
at the same time. If they could be applied simultaneously then they can't be
"only" can they??

Secondly there is the nature of the default flags.
The default seems to be no flags, which permits all access.
The flags (excepting secure delete and inherit) should then be defined as "deny"
flags.

EG: read_deny, write_deny, execute_deny, search_deny.
These can be combined logically without any semantic problems.

(what happens if you put execute_only and no_execute flags on together?)

Thirdly,  the interaction between inherited and explicit needs to expanded.
Either to have an inherit mask or to have tri-state flags (on, off, inherit)

Are you familiar with the Netware Flags? (as against trustees)
That is a pretty good model.

Probably a lot of work, but something to think about for the future.

Regards

John

-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.