... why are we worried about compatibility with NTFS? Or with distributed
file systems?
I'm not arguing that such support isn't a good idea, only that we seem
to be putting the cart before the horse here. Let's get *native* ACL
support into our filesystems. By "native" I mean that it uses the same
information we already require filesystems to understand (uid_t, gid_t).
N.B., as I understand ACLs they will be enforced by the file system
module, not the general kernel VFS level or user libraries. Unless
I'm mistaken the only extensions required to the VFS level are:
struct acl {
uid_t uid; /* uid or UID_ANY */
gid_t gid; /* gid or GID_ANY */
int permissions; /* R_OK, W_OK, X_OK, etc. */
};
ssize_t write_acls (int mode, const struct acl *acls, size_t size);
ssize_t read_acls (int mode, struct acl *acls, size_t size);
where mode = 0 for discretionary access control (user can modify)
and mode = 1 for non-discretionary access control (user can't modify,
but root or CAPACITY_NDAC(?) can.)
You don't need to have "positive" and "negative" flags if you follow
the policy that the best match dominates. You could remove 'bob' from
your group's permissions by:
(bob,group: ---)
(%,group: rw-)
Finally, once that's stable we can decide how to handle non-native ACLs
(e.g., those that require 128-bit UUIDs). We might lose some of the
transparency that VFS is intended to provide, but that's an unfortunate
reflection of the tremendous variety in how different groups handle ACLs.
I would hate to see us delay ACLs for months so we can handle NTFS,
only to have that filesystem be changed in a way that invalidates the
work.
Bear Giles
bgiles@coyotesong.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/