Bug 1227 - All ACEs dropped when setting more ACEs then the OS supports
Summary: All ACEs dropped when setting more ACEs then the OS supports
Status: RESOLVED LATER
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.12
Hardware: Other other
: P2 major
Target Milestone: none
Assignee: Jeremy Allison
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-29 09:56 UTC by Marc Kaplan
Modified: 2005-11-14 09:40 UTC (History)
0 users

See Also:


Attachments
A bz2 of a tar with a log.smbd and a sniff showing this problem happening (78.18 KB, application/bzip2)
2004-03-29 09:58 UTC, Marc Kaplan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Kaplan 2004-03-29 09:56:09 UTC
I'm using ACLs on XFS. The max number of ACEs is 10. I set 10, and all is fine. 
When I try to set 10 additional ACEs, all of the ACEs are removed except the 
UNIX perms for UGO. This is loss of data, I would say, and it could be 
disasterous for a customer who doesn't remember their exact permissions.

Previously, we just returned ACCESS DENIED when trying to set more than the OS 
max.

I've attached the log.smbd and a capture in Ethereal format
Comment 1 Marc Kaplan 2004-03-29 09:58:49 UTC
Created attachment 458 [details]
A bz2 of a tar with a log.smbd and a sniff showing this problem happening

This sniff and log.smbd shows:
1. Adding 10 ACEs successfully
2. Trying to more than the OS supports, which drops the ACEs set in 1
Comment 2 Jeremy Allison 2004-04-05 05:11:49 UTC
Ok, looking at the log I can't see the underlying system call giving an error on
the set - ie. there seems to be no error return on doing the set with more acls
than the system supports. Can you send me an strace showing this call, so I can
see what the OS is returning to smbd on the set ?
Jeremy.
Comment 3 Gerald (Jerry) Carter (dead mail address) 2005-03-21 19:42:44 UTC
moving back to 3.0
Comment 4 Gerald (Jerry) Carter (dead mail address) 2005-09-29 08:23:21 UTC
closing