attn: DCB - reproducing Solaris ACL bug...

[John Trostel]

What's the "test case" you are writting up? Is it running the acls through the
Samba code?

If you've got a snippet, send it this way and I'll try it on XFS too.

On 24-May-2001 Michael Davidson wrote:
>> On Thu, 24 May 2001, Gerald Carter wrote:
>> 
>> > >     Can you email me a slightly larger code snippit?
>> > >     I don't see this problem in bugtraq, and would
>> > >     like to reproduce it here...
>> > 
>> > I can code up a reproducable test case and send it to you.  Will work
>> > on that today.
>> 
>> ok.  This is beginning to get aggrevating.  My sample code works
>> fine... :-(  Let me dig back into lib/sysacls.c and see what I can
>> find.  grr....
>> 
>> 
> 
> I saw your messages about the problems with default ACLs under Solaris,
> and I constructed a test case similar to the one that you gave just to
> see if the same problem existed on UnixWare and, just like you, the test
> case works :-(
> 
> In the spirit of full disclosure I should admit that the Solaris / UnixWare
> ACL code has had almost no testing - after a few minor tweaks it pretty
> much 'worked first time' - John Terpstra and I tried a few simple things
> with it, but we really didn't do any systematic testing of all of the
> possibilities.
> 
> As I am sure you realise, the code for dealing with ACLs on directories
> is unpleasant since the Solaris acl() system call sets both the access ACL
> and the default ACL at the same time, but the POSIX ACL interface which
> Jeremy chose to use allows them to be set independently, so any time
> you try to set an ACL on a directory you always have to first of all
> retrieve the ACL that was already there ...
> 
> I have stared at the code for quite a while and really can't see how
> you could lose the individual group and user entries from the default
> ACL without losing the *entire* default ACL, but I haven't actually
> tried to debug this live so to speak.
> 
> A trace of all of the acl() system calls would be interesting ...
> 
> md

-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel at connex.com