Re: VFS 64-bit clean

Albert D. Cahalan (
Sat, 28 Feb 1998 15:56:06 -0500 (EST)

Remy Card writes:
> On Fri, Feb 27, 1998 at 08:25:46PM -0500, Theodore Y. Ts'o wrote:
>> I would agree with Albert Calahan that we should use i_dir_acl.
>> We can make sure the patches don't break by using #define's
>> for i_dir_acl.
> Well, the problem is that I chose quite a bad name for this field.
> Actually, i_dir_acl contains a pointer to the default ACL that can
> be set on a directory and is inherited by files and subdirectories.
> A file can have i_file_acl set (if it has an explicit ACL) or
> i_dir_acl set (if it has inherited the default ACL from its parent
> directory).

Pardon me, but that doesn't make sense. What happens when I change
the ACL on a file that already inherited an ACL? It seems that the
file would get two ACLs, which would be redundant or contradictory.
Either that, or you have one ACL that can go in two slots depending
only on how it was created -- which is a strange distinction to make.

Digital Unix puts an access ACL on files and an additional two ACLs
on directories. Access ACLs are never inherited. The default-access
ACL is inherited as the access ACL of new files and directories.
If it exists, the default-directory ACL overrides the default-access
ACL inheritance (becomes the new access ACL) for new directories.
Directories always inherit default-* ACLs as their own.

Using that, we would have:

i_access_acl Applies to everything
i_default_access_acl For directories only
i_size_high For files only
i_reserved_for_misc Available for symlinks, devices, etc.
i_default_directory_acl For directories only
i_reserved_for_files Available for non-directories

This is for Linux 2.3, right? (Linus announced a minor code freeze)
If you don't mind, I'd like to write a heavy-duty ACL system this fall.
It is possible to support the ACL features of many systems at the
same time, which is great for compatibility. Using the same number of
ACL fields as above, we can support the ACLs of Digital Unix, NT, Coda,
and Netware. Users get whatever interface they are most familiar with.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to