Date: Mon, 20 Aug 2001 10:39:46 -0400 (EDT) From: Chris BeHanna <behanna@zbzoom.net> To: <freebsd-fs@freebsd.org> Cc: <freebsd-security@freebsd.org> Subject: Re: DENY ACL's Message-ID: <Pine.BSF.4.32.0108201035050.9651-100000@topperwein.dyndns.org> In-Reply-To: <000f01c12982$321d68c0$0200a8c0@kjc2.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Aug 2001, Ken Cross wrote:
> > > The particular case you show would work, but others won't.
> >
> > I think that the example given below is the result of badly formed
> > security policy.
>
> Not really. There are real cases in large organizations where that
> configuration is perfectly legitimate. OTOH, it is often the result of
> "quick-fix" solutions. But that's the real world...
>
> >
> > > For example, suppose the user is a member of GroupA which is allowed
> access
> > > and also a member of GroupB which is denied access, e.g. "setfacl -m
> > > g:GroupA:rwx,g:GroupB: file". (There's no user-specific ACL.)
> > > All "deny" ACL's must be checked first, so the user should be denied.
> Under
> > > the current scheme, I think the "best match" would allow access.
> >
> > Yes, user will have access to file, but why shouldn't he have it?
>
> For whatever reason, the administrators decided to explicitly deny access to
> GroupB. By definition, that *must* be honored first. I don't make the
> rules, but I gotta live by them. ;-)
Perhaps I misremember, but weren't there access control systems
that use "first match" syntax? That would (partly) solve this
problem:
GroupB:
GroupA:rwx
Here, GroupB would match first, and the user would be denied; however,
another rule can be added:
UserA:rwx
GroupB:
GroupA:rwx
and all is well with the world.
--
Chris BeHanna
Software Engineer (Remove "bogus" before responding.)
behanna@bogus.zbzoom.net
I was raised by a pack of wild corn dogs.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.32.0108201035050.9651-100000>