NOTE: This info is not relevant to the near-term Fedora merge or any infrastructure supporting it. We will continue to use the existing CVS + ACL system.
Toshio was wondering about the possibility of using filesystem ACL's as part of a future ideal SCM's ACL enforcement. It would work something like this: 1) PackageDB knows about all packages, owners, granted permissions, groups, etc. 2) PackageDB generates xattrs or FS ACL (themselves based on xattrs) within the SCM files/directories. 3) SCM has a custom ACL enforcement script that reads those xattrs, making it very fast and flexible. ACL's could be enforced based on a list of users, groups, or a combination of users and groups.
I talked with a few filesystem experts within Red Hat. They said... - ext3 has a limit of 4KB for xattr data. If you use the standard encoding of 8 bytes per uid, that has a limit of roughly 100 entities that could be associated with a file. Is this too limiting? I dunno. Perhaps it need not be too limiting if more extensive use of group-based-ACL's are used. - XFS could possibly allow a maximum of 64KB xattr's per file, but that is very inefficient in filesystem storage. - xattr's are currently not supported by NFS.
Warren Togami wtogami@redhat.com
On Tuesday 20 March 2007 11:00:14 am Warren Togami wrote:
NOTE: This info is not relevant to the near-term Fedora merge or any infrastructure supporting it. We will continue to use the existing CVS
- ACL system.
Toshio was wondering about the possibility of using filesystem ACL's as part of a future ideal SCM's ACL enforcement. It would work something like this:
- PackageDB knows about all packages, owners, granted permissions,
groups, etc. 2) PackageDB generates xattrs or FS ACL (themselves based on xattrs) within the SCM files/directories. 3) SCM has a custom ACL enforcement script that reads those xattrs, making it very fast and flexible. ACL's could be enforced based on a list of users, groups, or a combination of users and groups.
Sounds very sane to me
I talked with a few filesystem experts within Red Hat. They said...
- ext3 has a limit of 4KB for xattr data. If you use the standard
encoding of 8 bytes per uid, that has a limit of roughly 100 entities that could be associated with a file. Is this too limiting? I dunno. Perhaps it need not be too limiting if more extensive use of group-based-ACL's are used.
I would like to encourage use of acls based on groups extensivly. i.e KDE SIG security etc. 8KB would probably be a little better but 4KB will be fine.
- XFS could possibly allow a maximum of 64KB xattr's per file, but that
is very inefficient in filesystem storage.
- xattr's are currently not supported by NFS.
i currently use linux ACL's over nfs very effectively
Dennis Gilmore wrote:
On Tuesday 20 March 2007 11:00:14 am Warren Togami wrote:
NOTE: This info is not relevant to the near-term Fedora merge or any infrastructure supporting it. We will continue to use the existing CVS
- ACL system.
Toshio was wondering about the possibility of using filesystem ACL's as part of a future ideal SCM's ACL enforcement. It would work something like this:
- PackageDB knows about all packages, owners, granted permissions,
groups, etc. 2) PackageDB generates xattrs or FS ACL (themselves based on xattrs) within the SCM files/directories. 3) SCM has a custom ACL enforcement script that reads those xattrs, making it very fast and flexible. ACL's could be enforced based on a list of users, groups, or a combination of users and groups.
Sounds very sane to me
I talked with a few filesystem experts within Red Hat. They said...
- ext3 has a limit of 4KB for xattr data. If you use the standard
encoding of 8 bytes per uid, that has a limit of roughly 100 entities that could be associated with a file. Is this too limiting? I dunno. Perhaps it need not be too limiting if more extensive use of group-based-ACL's are used.
I would like to encourage use of acls based on groups extensivly. i.e KDE SIG security etc. 8KB would probably be a little better but 4KB will be fine.
- XFS could possibly allow a maximum of 64KB xattr's per file, but that
is very inefficient in filesystem storage.
- xattr's are currently not supported by NFS.
i currently use linux ACL's over nfs very effectively
I forgot to mention this to the list but we are currently using ACL's effectively with the docs team. Basically all the translators have access to the doc's cvs /cvs/docs/*/po/ using the extended acls. I have a script that runs regularly that sets up these perms.
-Mike
I talked with a few filesystem experts within Red Hat. They said...
- ext3 has a limit of 4KB for xattr data. If you use the standard encoding of
8 bytes per uid, that has a limit of roughly 100 entities that could be associated with a file. Is this too limiting? I dunno. Perhaps it need not be too limiting if more extensive use of group-based-ACL's are used.
- XFS could possibly allow a maximum of 64KB xattr's per file, but that is
very inefficient in filesystem storage.
- xattr's are currently not supported by NFS.
The other thing to concider is backup and restore of acls and xattrs. I think this area is probably a weak spot as well but I believe star and rsync do have some kind of support for acls.
infrastructure@lists.fedoraproject.org