>> --- ./include/linux/ext2_fs.h.jj Mon Feb 9 17:50:54 1998
>> +++ ./include/linux/ext2_fs.h Wed Feb 25 09:17:03 1998
>> @@ -229,7 +229,10 @@ struct ext2_inode {
>> __u32 i_block[EXT2_N_BLOCKS];/* Pointers to blocks */
>> __u32 i_version; /* File version (for NFS) */
>> __u32 i_file_acl; /* File ACL */
>> - __u32 i_dir_acl; /* Directory ACL */
>> + union {
>> + __u32 i_dir_acl; /* Directory ACL */
>> + __u32 i_size_high; /* High 32bits of i_size for file */
>> + } un1;
>> __u32 i_faddr; /* Fragment address */
>> union {
>> struct {
>
> I would strongly recommend that we use i_faddr instead of i_dir_acl
> for this, since fragments are currently *completely* unused in all
> ext2fs variants, whereas there are patches waiting to be merged
> which use the acl fields.
i_dir_acl is only for directories
i_size_high is only for files
Would you ever have a 5 GB directory? Imagine how long you'd have
to wait just to do "ls -l" on such a directory. If needed, we could
even sacrifice the triple-indirect block for directories.
Inode space is precious, so the union makes sense. It seems you
missed some of the discussion about that. There are many other
features that must compete for inode space. We can't waste it.
Ignoring any unimplemented plans, the following are totally available
and AFAIK are zeroed:
i_file_acl ACL used on everything
i_dir_acl ACL used on directories (share with something else!)
i_res_fork could be merged in with ACL stuff
i_faddr never used
i_frag,i_fsize,i_pad1 never used
i_reserved2 already reserved
The following could be available for directories, if desperate enough:
i_block[14] directories larger than 64 MB are insane (too slow)
i_blocks can be calculated since directories can't have holes
I don't really think the current ACL and priv code should be merged.
Now that we have Coda and SMB, there are interesting new features that
could be supported throughout the system. For directories, the inode
could use some more ACL pointers -- like 36! Yeah, that could require
a larger inode. Digital Unix doubled the size of UFS inodes and Solaris
uses a second "shadow inode" to hold ACL information. Everything can
be done with two pointers (or even one), but that limits opportunities
to merge ACLs and inherit them without a copy.
Types of ACL:
ACCESS_ALLOWED AUDIT_SUCCESS ALARM_SUCCESS [privs too]
ACCESS_DENIED AUDIT_FAIL ALARM_FAIL
Inheritance control:
CONTAINER_INHERIT inherited by directories
OBJECT_INHERIT inherited by files, pipes, devices...
INHERIT_ONLY does not affect this inode
NO_PROPAGATE_INHERIT don't propagate CONTAINER_INHERIT and OBJECT_INHERIT
DEFAULT_DIR CONTAINER_INHERIT | INHERIT_ONLY | ???
DEFAULT_ACCESS OBJECT_INHERIT | INHERIT_ONLY | ???
PROPAGATE_INHERIT_ONLY needed to resolve Digital Unix vs. NT issues?
NO_PROPAGATE_INHERIT_ONLY maybe this instead, depending on default above
That seems to cover POSIX, Coda/AFS/DFS, Digital, NTFS/SMB...
I might get a chance to code it for credit next fall. The hard
part may be expanding the kernel to understand new permission
bits, since there would be 32 for each ID.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu