From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030709 Description of problem: Our deployment requires drop boxes for every department, with many users needing access to most boxes. Because of the 32 group limit (16 in Solaris), we've typically used ACL's for this application (Solaris 8). The EXT3 ACL's permit 32 entries per file/dir, only. This is obviously designed to prevent confusing, slow, or badly thought out security schemes, but 32 is just too low. JFS-unsupported supports several thousand, Solaris 8 supports 1024. For our purposes, 128 is plenty. The ACE's apparently need to fit in a single disk block, and maybe part of that space is being saved for other future things. But this just won't do. Please help to make EXT3 ACL support include enterprise scalability. Version-Release number of selected component (if applicable): kernel-2.4.21-1.1931.2.399.ent How reproducible: Always Steps to Reproduce: 1. Assign 28 ACE's with setfacl 2. 3. Actual Results: setfacl: <directory>: Invalid argument Expected Results: Additional ACE's should be applied Additional info: --- linux-2.4.20/include/linux/ext3_acl.h.orig Fri Oct 3 17:28:02 2003 +++ linux-2.4.20/include/linux/ext3_acl.h Fri Oct 3 17:28:15 2003 @@ -9,7 +9,7 @@ #include <linux/xattr_acl.h> #define EXT3_ACL_VERSION 0x0001 -#define EXT3_ACL_MAX_ENTRIES 32 +#define EXT3_ACL_MAX_ENTRIES 128 typedef struct { __u16 e_tag;
128 is too much for a single disk block on 1k filesystems (though it works on larger blocksizes.) This is a disk format issue, and there's no way that Red Hat can deviate from the upstream codebase on this point. Extending the limit on 4k blocksize filesystems may be possible but would lead to problems when moving or copying files between filesystems. And ultimately _any_ limit here is arbitrary, and _somebody_ will think it's too low. But I'll see what the upstream reaction is.
Andreas Gruenbacher's patch to ease the limit on reading large ext2/3 ACL lists has been accepted upstream. The corresponding patch for writes has not. I'll bring this up again to see if we can make progress. This is an on-disk format change, though --- old kernels will be unable to open files that are created with new kernels that use longer ACLs. So it's still not something we can do without a great deal of thought, and upstream acceptance.
Note: For my application, Tim Hockin's patch to remove the NGROUP hard limit that was merged in 2.6 is even more desirable than raising EXT3_ACL_MAX_ENTRIES.
Is this something that is still an issue or has everyone gone to RHEL-4 or can everyone go to RHEL-4? This is addressed in RHEL-4 and the limit there is somewhere just over 500 ACL entries. Since this issue has not been updated in 18 months, I would propose closing this as WONTFIX and suggest that people consider using RHEL-4.
Agreed. RHEL4 is OK with me. WONTFIX is acceptable.
Thanx. If this does turn out to be a significant issue for folks, then we can look at this decision again. It is getting late in the RHEL-3 lifecycle for changes like this, so perhaps considering a newer RHEL release might be the better choice in the long run anyway.