Re: two questions about ACL.

From: Amon Ott <ao@rsbac.org>
Subject: Re: two questions about ACL.
Date: Thu, 29 Mar 2001 09:29:14 +0200

Next Article (by Date): Re: Feature request for 1.2 (or for 2.0) Amon Ott
Previous Article (by Date): Feature request for 1.2 (or for 2.0) janos.milus@dataware.debis.hu
Top of Thread: two questions about ACL. "hollace leon"
Next in Thread: re: two questions about ACL. "hollace leon"
Articles sorted by: [Date] [Author] [Subject]

On Don, 29 Mär 2001 hollace leon wrote:
> I think there are some deficiency in ACL.
> 1.  the control on  SCD->others overrides  the control on certain a FILE(eg xxx.o).

I am not sure whether I got your message right. If you are talking about kernel
modules: There is no direct way to control, which files are loaded. The system
call only gets a memory area. So all we can do is use a general check for all
ADD_TO_KERNEL requests.

It is possible to have only certain users (or RC roles), who can open module
files and add to kernel.

If you find files, where access control does not work, please tell me. This
must be a bug.

> 2.  T_USER in ACL is useless. I assign a user "delete" right  to :DEFAULT:,
but got nothing.
 > 

It is not at all useless. The rights are all useful:

DELETE: You may use acl_rm_user to remove a user completely from all ACL
entries and all this user's groups. This is needed, because the kernel does not
(yet) know about legal user accounts.

READ/MODIFY_ATTR: Read or change log settings or pseudo, completely remove 
all attributes of a user

If we some day get real user account management in the kernel, there will
certainly be more rights, probably also for single user entries.

> maybe I lose myself in it?

Like most things, ACL is more complicated than many people think.

The ACL model description will be updated to make these questions clear.

Amon.
-
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.