Re: Understanding ACI

From: Amon Ott <ao@rsbac.org>
Subject: Re: Understanding ACI
Date: Tue, 20 Feb 2001 09:23:17 +0100

Next Article (by Date): Re: Understanding ACI Jörgen Sigvardsson
Previous Article (by Date): Re: Understanding ACI Jörgen Sigvardsson
Top of Thread: Understanding ACI Jörgen Sigvardsson
Next in Thread: Re: Understanding ACI Jörgen Sigvardsson
Articles sorted by: [Date] [Author] [Subject]

On Die, 20 Feb 2001 Jörgen Sigvardsson wrote:
> On Monday 19 February 2001 18:13, you wrote:
> > Just have a closer look into auth and acl data structures. Don't get
> > offended by the number of lists in there, there is a lot of copy, paste and
> > edit.
> I'm a teacher, I have graded labs, I don't get easily offended ;-)
> 
> However I would like to make a suggestion regarding the lists.. maybe an 
> abstraction of the lists would be in order? It would be nice if all list 
> functionality was separated from the rest of the code. I think that the level 
> of security is somewhat raised by such a move as well. Or maybe I should say 
> the confidence of security. Chain of reasoning: Less code -> lesser 
> likelyhood of bugs -> higher confidence.
> 
> I have seen that there is a list type in the mainstream kernel and a couple 
> of macros/functions for it, so I don't think there is more effort to it than 
> "rewriting" stuff.
> 
> I'm aware that this kind of work is probably not on the top of your 
> todo-list. But perhaps this would be appropriate for the next major? I'd be 
> willing to "convert" code. Am I being a nitpick now? :)

I already got some negative experience with these lists when I tried to extract
some useful info from one of them (without success). There are several reasons
why I decided not to use them:

- I could not find any useful documentation
- The lists are typeless - now I get compiler type checks, which tell me if I
got something wrong (in fact, the data storage is a nasty hack)
- Memory allocation without being sure about the size of the type is very
dangerous
- They would not save much code - the list handling itself is rather easy
- My lists have a significant speedup for repeated lookups via the curr pointer
- Spinlocks are directly associated with my lists.
- Most of my lists have to be persistent, so I need individual code for saving
the data only anyway

But we can discuss these things, if you like...

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.