ACL / SD support

[Michael Stockman]

Hello,

> I would recommend representing the HIDDEN, READONLY, and SYSTEM
attributes
> as one of these special meaning values.
>
> I noted in earlier post (SURS thread) that mapping the READONLY
attribute to
> the UID based protection has problems if you allow a user to toggle
it to
> allow writing to the file.  Representing this as a special identity
solves
> this problem, while adding another, in this case, that the host
system will
> not neccessarily honor it.

I don't quite follow you. I should perhaps point out that samba cannot
alter your unix system and support more than it can.
Second, are attributes stored in the ACL/SD? I don't think I've seen
it on NT and I doubt on unix.

> The reporting of the ARCHIVE bit should be done by a platform
dependent
> routine so that it accurately represent the backup state of the
file.
> Setting the archive bit would have a similar routine, for those
platforms
> that it makes sense.  A smb.conf option that specifies if a non-root
user is
> allowed to change the ARCHIVE bit may also be desired.
>
> If it is desired to have the state of the following attributes
reported and
> or updated from a Windows system, then they can also be represented
as
> special meaning values:
>
> sticky, setuid, setgid, manditory locking, append only, etc...

If I'm correct, you want samba to check for these file attributes and
have samba create ACL entries with special users in case they are
there? If so, you don't need special values, you need ordinary users
that are interpreted specially in the read and write SD functions,
because NT must know the user. Your suggestion counts as a hack.

> A default protection and inheritance type is needed.  This is
implemented in
> NT 4.0 SP4.  The commands to display and manipulate this are in W2K
or a
> patch kit for NT 4.0.

I don't quite see what you are asking for.

> What should the behavior be on host platforms that support ACLs
natively?

File system ACLs should go about their own business just like now (it
won't be replaced by anything). Our internal objects won't be
protected by any systems ACLs, so they'll be protected by our own on
any system.

> It would seem that the code would need to be customized for many
platforms.

Certain areas would need to be (reading and writing SDs), other will
not.

> For the host systems that do not support ACLs:
>
> Where will this information be stored?

I won't. Some could in some cases be saved, it depends on what the
file system supports and doesn't support. I should make it clear that
I'm not aiming at samba replacing the unix file system security, just
being able to use it.

> What happens to the Security Descriptor information when a file is
deleted
> on the host operating system?

Same thing as today, it is stored by the file system and should be
lost by the file system when the file is deleted.

> How does the Security Descriptor information get propagated to a new
version
> of a file when using a native UNIX utility such as VI or EMACS?

I don't see what you mean.

Best regards
  Michael Stockman
  pgmtekn-micke at algonet.se