Add support for ACLs

[vreixo]

Nowadays optical media has a price/capability relation good enought to make it suitable for backup purposes. With RockRidge? extensions, that offer a POSIX support over limited ISO-9660, one can make a backup of his/her system that is easily mountable anywhere, thus making restore of backup files more easily.

However, RR still lacks support for Access Control Lists (ACL). For full-featured backup capabilities, such support is needed. Indeed, it would be great to have support for them on isofs Linux kernel driver. That way such info would be automatically recognized when mounting the image.

SUSP extensions RR are based on are a good candidate for this support. Moreover, a good idea would be to implement them as a Linux-specific RR extension, in the same way zisofs is implemented.

Please post your comments.

[scdbackup]

Where can i learn about SUSP ?

In general i have few hope for acceptance in Linux. But xorriso could make use of them with its future option -restore.

[vreixo]

Where can i learn about SUSP ?

SUSP: ftp://ftp.ymi.com/pub/rockridge/susp112.ps RR: ftp://ftp.ymi.com/pub/rockridge/rrip112.ps

in fact, instead of a new SUSP extension, I really prefer a RR extension such as zisofs. I would try to get on-driver support on linux, but anyway reading capabilites of libisofs (via IsoFilesystem? or image import) must be able to access this new feature.

[scdbackup]

Future is past now: -restore is called -extract and works well. Now if we could encode and decode ACLs in the ISO image then we could restore them to disk independently of mount.

---

Vreixo asked me to dump here what i learned about ACL meanwhile:

Currently it looks like we will have to store about a hundred bytes of ACL poetry. See man 5 acl "LONG TEXT FORM". See output of command getfacl.

Functions acl_to_text() and acl_from_text() are the interface from app to the libacl world. Functions acl_get_file() and acl_set_file() are the interface between libacl world and the filesystem.

libisofs will possibly use acl_get_file() and acl_to_text() directly and/or accept ACL text strings from the app to attach them to IsoNode objects. It will vice versa have to deliver the ACL texts from IsoNode to app.

xorriso will use acl_from_text() and acl_set_file() to restore ACLs from ISO/RR image to filesystem. The lenghty form of ACL text and the redundancy which has to be expected from ACL inheritence point towards compression and de-duplication. Questions: Which compression ? A Huffman tree ? Is there a way to have non-file text storage in the image ? So that we could point from many nodes to the same ACL text.

We should consider this hint from man 5 attr: "additional security features such as Access Control Lists (ACLs) may be implemented using extended attributes."

I.e. strive for Extended Attributes in general and implement our ACLs on top of them. (Regardless whether we store whole ACL poems with the nodes or whether we store only keys to an ACL table.)

So we would need a RR and libisofs facility which stores pairs of names and text values, where at least the text value can be quite lengthy.

There seems to be already an attribute name defined for ACL: "system.posix_acl_access". But the getattr command does not show any attributes with a file where getfacl shows ACLs. So one would have to dig for the representation of ACL values in Extended Attributes - or invent an own one.

[vreixo]

Some notes about a format for ACLs as a RR extension.

From acl(5) I get this information:

- A file may have an access ACL - A dir may have an access ACL and a default ACL - An ACL is a set of ACL entries - An ACL contains three atributes

• Entry tag type. Any of ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_MASK, ACL_OTHER
• Entry tag qualifier (optional), either uid (for ACL_USER) or gid (for ACL_GROUP), none for other tag types.
• Permissions

So to store an ACL entry we need 3 bits for tag type, 32 bits for gid/uid and 3 bits for permissions, so an ACL entry will need either 38 bits (for ACL_USER or ACL_GROUP types), or only 6 bits (for other types).

And, of course, we need a header with a single bit for the ACL list type (access/default) and the number of entries.

Thus, it seems easy to define a compact format for storing ACLs as RR entries. I will write a specification, send to list for review, and then submitted to kernel developers. If we get this accepted in linux kernel it would be great.