Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Aug 2001 21:37:06 -0400
From:      "Jonathan Slivko" <js43064n@pace.edu>
To:        Ken Cross <kcross@ntown.com>, Robert Watson <rwatson@freebsd.org>
Cc:        <freebsd-security@freebsd.org>
Subject:   Re: DENY ACL's
Message-ID:  <200108192137.AA78709278@stmail.pace.edu>

next in thread | raw e-mail | index | archive | help
But there is 1 thing that both of you forgot to account for, 
how much load it would take in order for the deny ACL's to be 
loaded and to be read, several times over in a given hour. Any 
comments on that front? -- Jonathan

--
Jonathan M. Slivko                  js43064n@pace.edu
Head Systems Administrator          4EverMail Hosting Services
--



---------- Original Message ----------------------------------
From: Robert Watson <rwatson@freebsd.org>
Date: Sun, 19 Aug 2001 21:29:59 -0400 (EDT)

>
>On Sun, 19 Aug 2001, Ken Cross wrote:
>
>> The current Posix.1e ACL implementation in -current works great 

as far
>> as it goes.  I'm sure this has been kicked around before 

(although I
>> couldn't find anything in the archives), but it seems like 

adding "deny"
>> ACL's would be a useful and fairly straightforward extension. 
>> 
>> For those not familiar with it, deny ACL's are ACL's that 

explicitly
>> deny access, e.g., group Accountants are allowed access, but 

user George
>> is denied access even though he is a member of Accountants. 
>>
>> They are used extensively in the Windows NT/2K world and I need 

to
>> support them on a BSD platform.  The implementation is pretty
>> straightforward -- always check deny ACL's first and then 

access ACL's. 
>> They'd just be a new acl_type_t value (ACL_TYPE_DENY?). 
>> 
>> I'd be happy to help with the implementation (especially since 

I'll be
>> doing it regardless).  Any interest or things I should know 

about? 
>
>There are some interesting questions about how you would combine 

the
>POSIX.1e ACL evaluation with subtractive rights of the sort 

you're
>talking
>about.  POSIX.1e does evaluation by a combination of first/best 

match.
>It evaluates based on a "first match" of the general class of 

rights, and
>then "best match" within that class.  Here's the current 

algorithm based
>on what's defined in POSIX.1e:
>
>Select a "matching" class using the following:
>
>(1) if effective uid == the file owner, then the file owner 

permissions
>are used
>
>(2) if the effective uid == one of the additional users, then the
>additional user permissions in question are used
>
>(3) "best match" from effective gid and additional groups using 

the base
>group permissions and additional groups.  "best" in this case is 

defined
>as the first gid match that grants all the rights requested.  I 

don't
>believe that, in the event there are multiple matches, there is a 

defined
>ordering for the match, but in the FreeBSD implementation, it 

matches the
>effective uid before additional groups. 
>
>(4) other
>
>So, if you want "subtractive rights" that mix with positive 

rights, we'll
>actually need to fundamentally modify how the algorithm executes. 

 Right
>now, it is possible to express some sorts of "negative" rights by 

taking
>advantage of knowledge of the fixed matching components of the 

algorith;
>the "best" matching in the group section does foil some useful 

attempts.
>
>You might want to bring this up on the POSIX.1e mailing list, 

btw, and see
>what thoughts the developers of other platforms have on the 

topic, or
>whether this has been approached on other POSIX.1e-esque 

platforms.  I'm
>glad that the existing ACL implementation is coming in useful for 

you.
>
>Robert N M Watson             FreeBSD Core Team, TrustedBSD 

Project
>robert@fledge.watson.org      NAI Labs, Safeport Network Services
>
>
>To Unsubscribe: send mail to majordomo@FreeBSD.org
>with "unsubscribe freebsd-security" in the body of the message
>
 

__________________________________________________________________
____
Sent via the Pace University Mail system at stmail.pace.edu


 
                   

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108192137.AA78709278>