Bug 106252 - RFE: EXT3_ACL_MAX_ENTRIES too low
Summary: RFE: EXT3_ACL_MAX_ENTRIES too low
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Staubach
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-04 04:05 UTC by Christopher Barton
Modified: 2007-11-30 22:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2006-03-23 19:52:22 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Christopher Barton 2003-10-04 04:05:21 UTC
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):

How reproducible:

Steps to Reproduce:
1. Assign 28 ACE's with setfacl

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;

Comment 1 Stephen Tweedie 2003-10-14 11:27:40 UTC
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.

Comment 3 Stephen Tweedie 2004-09-10 14:04:02 UTC
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.

Comment 4 Christopher Barton 2004-09-15 23:08:22 UTC
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

Comment 6 Peter Staubach 2006-03-23 19:30:55 UTC
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.

Comment 7 Christopher Barton 2006-03-23 19:49:11 UTC
Agreed.  RHEL4 is OK with me.  WONTFIX is acceptable.

Comment 8 Peter Staubach 2006-03-23 19:52:22 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.