Posix Extended headers ...
Joerg Schilling
schilling at fokus.gmd.de
Tue Jul 16 06:22:02 GMT 2002
>From rsharpe at ns.aus.com Mon Jul 15 19:47:35 2002
>[Added Samba-technical so that this discussion can be recorded]
I added Andreas Gruenbacher. He is the one who works on the Linux ACL
implementation.
>Preamble. Noting that star supports saving and restoring Posix ACLs for at
>least Linux, and that Samba's libsmb now has routines to query and set
>SEC_DESCs, I started talking to Joerg Schilling on this topic.
star supports ACLs for Solaris, Linux, FreeBSD.
True64 does not work completely because True64 is based on an outdated POSIX ACL
proposal. However, there could be support if we would replace the ACL library
with a self made lib.
IRIX may work completely but I did not yet get a feedback.
You see, the current implementaion as described in
http://acl.bestbits.at/star.html
and
ftp://ftp.fokus.gmd.de/pub/unix/star/README.ACL
does already allow to move ACLs between different platforms.
>> Mmm, Audit entries on Solaris are kept in the shadow passwd file.
>I think audit entries are similar to positive or negative ACEs, and simply
>mean that if the specified user/group requested the specified access,
>write a system log entry.
Audit entries on SunOS first appeared with SunOS 4.0 (in 1987) and are
handled locally in a machine specific database. As they are not limited to
filesystem specific calls, I believe it does not make sense to attach them to
files execpt when you are limited to files and do not like to do the name
filtering later - on Solaris AFAIK, you need to specify e.g. audit all chmod()s
for this user and later the audit daemon filter needs to check the file names.
Audit entries will for this reason not fit into the POSIX model at all. We may
chose to use a disjunct storage in the POSIX extended header.
>> - Denial default entries (descending information starting from dirs)
>>
>> - Denial access entries
>>
>> These could just look (besides the label) the same as the existing entries.
>That is a neat idea. That would make it work. We would want to record
>user/group names as DOMAIN\name as well, and UID/GID does not necessarily
>make sense.
User/group names alone are not sufficient on UNIX and I suspect that they are
not sufficient on NT too. Just imagine that you back up a file server that does
not know about the user names.
I am not sure what the DOMAIN/name concept should be. If it is a limitation for
the validity of "name" then I would understand.
>> >Translating them to text would allow system independent restores, so a
>> >backup from a Windows NT/2K domain could be restored on an NFS V4 server,
>> >or indeed on a system with POSIX ACLs with some loss of information.
>>
>> Not translating them to text could make archives a lot less portable.
>Yes, it was simply mentioned as a first-cut stop-gap solution.
We did not attempt to do anything similar for UNIX. While it may make sense to
do it in internal versions, public versions should use a more or less final format.
>> Creating a ACL aware SMB backup could be done by either adding POSIX.1-2001
>> support to smbclient, or by adding a smb access lib to (a specialized) star.
>Hmmm, might be similar amounts of work in either case. Does star have a
>library-feel for the code that writes headers/blocks to the archive?
star has more than 100 options, it would be hard to put this into a library. Is
is possible to get the smbclient code as library?
>There is a library in Samba that provides much of what you want but is
>perhaps not so easy to use as yet.
>I imagine that the ACLs are written as a header and block that contain the
>ACL.
The benefit of the POSIX extended header is that it allows to add any amount of
information into a single container. This is the reason for the extendability.
Jörg
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling at fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
More information about the samba-technical
mailing list