AFS to NFSv4 ACL conversion

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
Line 13: Line 13:
         loc(k)
         loc(k)
-
Perms set only on directories in AFS, also allowed on files, symlinks,
+
Perms set only on directories in AFS, also allowed on files, symlinks, mount points in auristor.  r/w/k perms on directory control files in
-
mount points in auristor.  r/w/k perms on directory control files in
+
that directory that don't have an ACL set.
that directory that don't have an ACL set.
So in auristor it's possible for a file to not have any ACL set.
So in auristor it's possible for a file to not have any ACL set.
-
I assume that directories do have ACLs set, and new subdirectories
+
I assume that directories do have ACLs set, and new subdirectories inherit same permissions as parents.
-
inherit same permissions as parents.
+
-
Both also allow 8 additional application-defined permissions A-H which
+
Both also allow 8 additional application-defined permissions A-H which I think we'll ignore.  (If necessary, write a v4 protocol extension.)
-
I think we'll ignore.  (If necessary, write a v4 protocol extension.)
+
"Negative permissions" always take precedence.
"Negative permissions" always take precedence.
Line 32: Line 29:
Anyway, AFS->NFSv4 translation algorithm:
Anyway, AFS->NFSv4 translation algorithm:
-
Given a directory: Start with an empty NFSv4 ACL.  Iterate through the
+
Given a directory: Start with an empty NFSv4 ACL.  Iterate through the ACEs of the AFS ACL one at a time, negative ACEs first. For each ACE:
-
ACEs of the AFS ACL one at a time, negative ACEs first. For each ACE:
+
* If the AFS ACE is a negative ACE, any new NFSv4 ACEs generated in this step should be ACCESS_DENIED_ACE, otherwise ACCESS_ALLOWED_ACE.
* If the AFS ACE is a negative ACE, any new NFSv4 ACEs generated in this step should be ACCESS_DENIED_ACE, otherwise ACCESS_ALLOWED_ACE.
Line 50: Line 46:
Failures on mapping to NFSv4 ACLs:
Failures on mapping to NFSv4 ACLs:
-
* Without server (and client userspace tool) support for the NFSv4.1 DACL attribute and automatic inheritance, changes to
+
* Without server (and client userspace tool) support for the NFSv4.1 DACL attribute and automatic inheritance, changes to directories won't automatically propagate to children.  This is different from AFS, where the directory ACL controls permissions on all clients (and Auristor, where that's still the default behavior although files may optionally have their own ACLs).
-
directories won't automatically propagate to children.  This is different from AFS, where the directory ACL controls
+
-
permissions on all clients (and Auristor, where that's still the default behavior although files may optionally have their own ACLs).
+
Failures on mapping to POSIX ACLs as implemented on Linux:
Failures on mapping to POSIX ACLs as implemented on Linux:
-
* POSIX ACLs are unable to distinguish between insert and delete.  The mapping should default to erring on the side of
+
* POSIX ACLs are unable to distinguish between insert and delete.  The mapping should default to erring on the side of restrictiveness, and deny directory write permissions when insert and delete are not both permitted.
-
restrictiveness, and deny directory write permissions when insert and delete are not both permitted.
+
* POSIX ACLs inherit parent permissions only on creation, there's no way to emulate AFS behavior.
* POSIX ACLs inherit parent permissions only on creation, there's no way to emulate AFS behavior.
-
* POSIX ACL inheritance is very different: directories have an "access ACL" (which determines permissions) and a "default
+
* POSIX ACL inheritance is very different: directories have an "access ACL" (which determines permissions) and a "default ACL" (which is inherited by children).  The default ACL is inherited by both files and directories, and POSIX ACLs use the same bit for, for example, directory modification and file write.  This means, for example, it's not possible to set an inheritable ACL giving child files write permission but denying modification permissions to child directories.  In such cases by default we should err on the side of denying both permissions.
-
ACL" (which is inherited by children).  The default ACL is inherited by both files and directories, and POSIX ACLs use
+
-
the same bit for, for example, directory modification and file write.  This means, for example, it's not possible to set an
+
-
inheritable ACL giving child files write permission but denying modification permissions to child directories.  In
+
-
such cases by default we should err on the side of denying both permissions.
+
-
Whenever we're unable to map permissions exactly, we should default to erring on the side of denying permissions, and warning the user.  A
+
Whenever we're unable to map permissions exactly, we should default to erring on the side of denying permissions, and warning the user.  A conversion tool may provide ways to override that default and the warnings.  Care must be taken to prevent warnings from being unmanageable.  When converting large filesystems, we should provide a readable summary and give the user a way to get the details if necessary.
-
conversion tool may provide ways to override that default and the warnings.  Care must be taken to prevent warnings from being
+
-
unmanageable.  When converting large filesystems, we should provide a readable summary and give the user a way to get the details if necessary.
+
Some remaining questions:
Some remaining questions:
-
* interactions with mode bits: in the past I believe AFS simply ignored mode bits, allowing us to ignore them on conversion.
+
* interactions with mode bits: in the past I believe AFS simply ignored mode bits, allowing us to ignore them on conversion. I think that may no longer be true for AFS (or at least for Auristor).
-
I think that may no longer be true for AFS (or at least for Auristor).
+
* user & group naming
* user & group naming
* file owners and groups
* file owners and groups

Revision as of 02:26, 14 August 2020

Sources:

directory:

       (l)ookup
       (i)nsert
       (d)elete
       (a)dminister

file:

       (r)ead
       (w)rite
       loc(k)

Perms set only on directories in AFS, also allowed on files, symlinks, mount points in auristor. r/w/k perms on directory control files in that directory that don't have an ACL set.

So in auristor it's possible for a file to not have any ACL set.

I assume that directories do have ACLs set, and new subdirectories inherit same permissions as parents.

Both also allow 8 additional application-defined permissions A-H which I think we'll ignore. (If necessary, write a v4 protocol extension.)

"Negative permissions" always take precedence.

Auristor docs state that "i" is equivalent to "w" permissions when applied to a file. That rule is so strange I'm inclined to ignore it.

Anyway, AFS->NFSv4 translation algorithm:

Given a directory: Start with an empty NFSv4 ACL. Iterate through the ACEs of the AFS ACL one at a time, negative ACEs first. For each ACE:

  • If the AFS ACE is a negative ACE, any new NFSv4 ACEs generated in this step should be ACCESS_DENIED_ACE, otherwise ACCESS_ALLOWED_ACE.
  • Create two NFSv4 ACEs, one with ACE4_DIRECTORY_INHERIT_ACE set, the other with NFS4_ACE_INHERIT_ONLY_ACE and NFS4_ACE_FILE_INHERIT_ACE set. On the first ACE, set mode bits as follows:
       l->ACE4_EXECUTE|ACE4_READ_DATA
       i->ACE4_WRITE_DATA|ACE4_APPEND_DATA
       d->ACE4_DELETE_CHILD
       a->ACE4_WRITE_ACL

On the second ACE, set mode bits as follows:

       r->ACE4_READ_DATA
       w->ACE4_WRITE_DATA|ACE4_APPEND_DATA
       a->ACE4_WRITE_ACL.
  • Given a file: the same, but create only one ACE, with no inheritance bits set. If the source file has no AFS ACL, then the ACL on the destination file should be exactly what it would be if it was inherited from its parent. If the source file has an ACL, then determine the access bits on each destination as above, ignoring any l, i, or d bits. In addition, if the destination NFSv4 server supports the dacl attribute, then set ACE4_INHERITED_ACE on all ACEs when the source file has no AFS ACL, and set ACL4_PROTECTED on any flag on any ACL for which the source file has an AFS ACL set.

I don't think there's any way to handle loc(k) correctly. It should be just ignored and documented. ACE4_SYNCHRONIZE is vaguely similar but in practice it won't do the right thing on any NFSv4 server. A Linux server will ignore it, and a server that supports it probably uses read or write opens to decide permissions to lock, as is traditional for linux/unix.

Failures on mapping to NFSv4 ACLs:

  • Without server (and client userspace tool) support for the NFSv4.1 DACL attribute and automatic inheritance, changes to directories won't automatically propagate to children. This is different from AFS, where the directory ACL controls permissions on all clients (and Auristor, where that's still the default behavior although files may optionally have their own ACLs).

Failures on mapping to POSIX ACLs as implemented on Linux:

  • POSIX ACLs are unable to distinguish between insert and delete. The mapping should default to erring on the side of restrictiveness, and deny directory write permissions when insert and delete are not both permitted.
  • POSIX ACLs inherit parent permissions only on creation, there's no way to emulate AFS behavior.
  • POSIX ACL inheritance is very different: directories have an "access ACL" (which determines permissions) and a "default ACL" (which is inherited by children). The default ACL is inherited by both files and directories, and POSIX ACLs use the same bit for, for example, directory modification and file write. This means, for example, it's not possible to set an inheritable ACL giving child files write permission but denying modification permissions to child directories. In such cases by default we should err on the side of denying both permissions.

Whenever we're unable to map permissions exactly, we should default to erring on the side of denying permissions, and warning the user. A conversion tool may provide ways to override that default and the warnings. Care must be taken to prevent warnings from being unmanageable. When converting large filesystems, we should provide a readable summary and give the user a way to get the details if necessary.

Some remaining questions:

  • interactions with mode bits: in the past I believe AFS simply ignored mode bits, allowing us to ignore them on conversion. I think that may no longer be true for AFS (or at least for Auristor).
  • user & group naming
  • file owners and groups
Personal tools