No subject

text formats are defined. In both the short and long form, ACL entries are
encoded identically; the difference is how entries are separated. The long
text form supports comments between the ACL entries.

On page 50, it says:

[] Each <acl_entry> line shall contain one ACL entry with three required
[] colon separated fields: an ACL entry tag type, an ACL entry qualifier,
[] and the discretionary access permissions. An implementation may define 
[] additional colon separated fields after the required fields.

So we can simply add an additional field after the permissions, resulting
in this long form:

#some comment
user::rw-
user:joe:rw-:511	#and here another comment
group::r--
mask::rw-
other:---

which is equivalent to this short form (modulus comments):

user::rw-,user:joe:rw-:511,group::r--,mask::rw-,other:---

So actually Michael, you were pretty close  :-)

Does anybody want to raise any issues against using this as the backup
format?

> Why archiver can not have it's own variant of acl_to_text() ?

Yes it can have that. And with the ACL entry manipulation functions
defined in draft 17, the ACLs could be reconstructed. However since many
platforms don't implement all of draft 17, it would be easier to construct
a string that can then be passed to acl_from_text().

Since both the FreeBSD folks (Robert) and the Linux guys (we) are thinking
about the problem right now, we might as well have a function that does
that portably across at least the two platforms (maybe others will
follow).

> Again, refering to solaris, all acl_t internals visible to
> application, and definition is quite the same as in-kernel structures
> used [...]

You can do that on Solaris, true. On Linux, the extended attribute
representation of an ACL isn't quite that simple (but the format used has
other benefits). That's exactly the reason why the Posix functions have
been specified. You have to blame Sun for not implementing them.

> [...]
> > As I understand the specs, the `security.' prefix is reserved for ACLs and
> > similar objects. The names `security.acl.access' and
> > `security.acl.default' should be fine.
> 
> Still don't understand why we need _two_ of them. [...]

The ACL and Default ACL are two separate entities for different purposes.
The Posix interfaces treat them completely separately. Just for
convenience, the Linux and Solaris userspace utilities can display both
types of ACLs at once. The Posix utilities don't support this.

I will not merge the two types of ACLs. This would lead to incompatibility
with Posix, added complexity in the code (believe me, the kernel code
complexity really reduced when I split them), and would probably cause
even more trouble with respect to future development.

> [...]
> > A useful check would be to compare the file mode permission bits
> > against the ACL entries. I would give the ACL precedence in case of
> > conflicts, on filesystems that support them. On other filesystems, the
> > file mode permission bits might be a better choice.
> 
> Again for this to work app needs to either parse acls on its own or
> to have access to contents of acl_t type.

This is possible with the Posix functional interface. If you need to do
this on Solaris or another non-compliant platform, chances are you will be
able to very quickly port one of the free ACL libraries (mine?) to
Solaris to build portable applications there.

> P.S.  Noone of tar/cpio/dump authors replied to my
> requests/questions/proposals yet, dump-devel list is also quiet.

I'm sorry about that. Did Paul Eggert also stay mute? He should have some
interest in that...

> This seemed to be funny: people can't just use acls (e.g) because
> there are no support for them in basic utils, but to made this support
> people needs to use acls...  Like kitchen/eggs problem... :)

What are the specifics of that particular problem? Shouldn't there be a
chicken around, too?


Regards,
Andreas

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher at computer.org
 Contact information: http://www.bestbits.at/~ag/

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message