Red Hat Bugzilla – Bug 54218
User with too many groups causes permission denied..
Last modified: 2007-04-18 12:37:26 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913 Description of problem: I'm running the 7.1.94 build of Roswell. I have about 200 users and about 250 groups. For backup reasons I have a user account that I also made a member of all the user private groups as well as the independant groups I created, but not including any of the built-in groups shipped with RedHat (like wheel, or disk). If I take that user and go to a directory that has group write access, I cannot create files. If I try to edit a file that has group write access, the editor opens it as read-only. I can even change the directory or file to be mode 777 and it will still say I don't have permission. I found that the problem is the number of groups. If I start removing the number of groups the account is a memeber of, It will eventually work, without having to modify the directory of file permissions. I can also revert the permissions to the original value, and it will work like it's supposed to. I then re-added a single group, and I would get the permission problems again. To see if it was that last particular group..I removed the last group, and another one further in the file. I suspect I'm overflowing some variable or something Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.create about 200 groups 2.create a user, and make them a member of all 200 groups you created 3.create a directory writeable by one of your groups 4.try to create a file Actual Results: You get a permission denied Expected Results: Should be able to create the file. Additional info: I'm running the ext3 filesystem.
This looks like a kernel limit (usually set to 32 or so). Arjan, any way to work around this without rebuilding the kernel?
This is accually a libc thing iirc. You can just use the 'chgrp' command to change your primary group and it'll work fine.
Just doing a 'chgrp' doesn't help from samba, which is why I need it to actually work correctly. I just used the described technique to verify that the problem wasn't samba's.
We don't plan to address this limitation. There has been some 2,5 discussion about it and the general opinion is not to do so. In paticular things like NFS have this limit built into the protocol