NT ACL / Security descriptor checking function

Michael Stockman pgmtekn-micke at algonet.se
Sat Feb 12 10:21:42 GMT 2000


> On Sat, 12 Feb 2000, Michael Stockman wrote:
> > > On Sat, 12 Feb 2000, David Collier-Brown wrote:
> > >
> > > ok.  what you do is you implement vfs-table "modules" that
> > > different filesystem mappings.  the API takes NT security
> > descriptor.

Really, when you read the ACL from disk (or the net) you store it in
our format (with no loss of information). Then, when you write an ACL
to disk (or the net) you convert it to the host (file system or NT)
format. This is where the loss of information may occur and should
occur. I need the format of the ACL to guarentee that the loss of
information doesn't occur before the ACL is written (and that is what
NT doesn't).

> > Actually, what I want is a "can do it all" ACL implementation. And
> > that is why we must own the implementation, not be depending on
> > someone not having this requirement. I don't trust that NT ACLs is
> > superset of all ACL implementations.
> ok, that's a good enough reason to consider a "higher-level" ACL
> [i'm going to avoid using "NT" now in case you have something
against NT.
> if you had used a word other than "trust", i would not fel the need
to do
> this].

The issue is that NT hasn't promised to support every kind information
that may be contained in an ACL on any kind of system samba may be
used on.

> for example, that rainbow book talks about restricting access on a
> per-time-of-day basis, which is fairly... extreme!

Yes, and someone may implement it somewhere and then I would want to
be able to extend our implementation, not completely rewrite it.

> my suspicions are that you won't find any real-world ACL
> that are any better than the VAX/VMS security model (on which NT is
> based).  and if theree are any, it's probably going to be very few
> features that do not have VMS-equivalents.

Yes, this may be true today. I wouldn't couldn't say for tomorrow or
ten years from now.

> then agian, neither of us are authorities on the subject.
> my suggestion would be, simply to avoid duplicating effort to
produce an
> ACL api that is a [potential] superset of VMS-security descriptors,
is to
> _use_ VMS-security descriptors as the baseline, until it can be
> that there exists a real-world ACL impleentation that does more.

Actually there is from a coding point a very small difference between
these. Our implementation will need to support standard UNIX rights
and full NT rights (and should be flexible enough to support other
rights too). The actual processing of ACLs is AFAIK common from system
to system, possibly with semantic differences.

The difference is that we may own the data in the ACL (and provide the
necessary mapping functions) or we may say that this is an
implementation of VMS/NT ACLs in which case we will need to use their
bits (and should they ever change ..., i don't want to think about

> jeemy has done a perfectly good job of coming up with heuristics to
> VMS security descriptors into a unix file permissions.  from what i
> understand, the rules are simple: throw away any bits you can't use.
> they're only going to be useful to us (the remaining bits)

Would that be the NT bits that the file system doesn't support?
Suppose that the file system has bits NT doesn't support, that aren't
ever sent to NT, and that the NT user wouldn't have changed if he had
know about them? There could be reason to apply "diffs" to ACLs rather
than straight sets.

> it should therefore be a trivial job to examine that code and
create, say,
> a POSIX-based ACL implementation.
> or, john malmberg to do a VMS-based one.

Which would only be two mapping functions (one read and one write) for
every kind of ACL we ever want to support.

> > I want this because I think it is the most obvious that we on a
> > system sets permissions using the POSIX id. Rationale, samba is
> > NT is NT and they meet on the net, not on the POSIX system.
> please read
http://cb1.com/~lkcl/cifs/draft-lkcl-sidtouidmap-01.html, i've
> already covered exactly this issue, i'm not discussing it again in
> please refer to the section that covers VMS ACL to POSIX ACL or unix
> permission conversion.

I could find no section with relevance to if the identifier in an
internal ACL representation in samba should be uid/gid/other based or
SID based. As the rainbow paper said, a POSIX ACL implementation is
not restricted to only work with uids and gids, other classes are
acceptable too which could make them fully NT compatible.

Best regards
  Michael Stockman
  pgmtekn-micke at algonet.se

PS I'm working on some code as we discuss.

More information about the samba-technical mailing list