[Samba] Re: still ACL bug in 3.0.14a

[Tom Schaefer]

On Tue, 19 Apr 2005 20:44:24 -0500
"Jeremy Allison" <jra at samba.org> wrote:

> This is actually a separate (non-ACL) issue. It's not a bug in
> the ACL code. I reproduced it last night and am preparing a 
> response - the problem is the DOS attributes code sees it as
> read-only. Do a attrib <filename> command from a Windows client
> and you'll see +r at the attribute. It's not strictly a Samba
> bug, more a design issue.
> 

I agree, its more of a design issue.  Jeremy since you "haven't yet
decided exactly what semantics make sense here.".. 

My 2cents (which I realize no one has asked for but thats the beauty of
internet mailing lists) is that by default for any writeable share the
user & group on whos behalf Samba is acting should have the exact same
permission to modify a file or delete it or whatever that they'd have
where they actually logged into the Samba server via a UNIX shell.

That is how I as a Systems Administrator have come to expect Samba to
behave and to the best of my knowledge is how it does behave outside the
particular issue we are discussing.  

As for the read only attribute on a file, I think if the user & group
combination on who's behalf Samba is acting would have the ability to
write to the file where they sitting at a UNIX shell then the read only
flag should not be set and vice versa.

> I'm at LinuxConfAu at the moment but 2619 isn't a real bug
> as if you typed "attrib -r <filename>" it would fix the problem.
> 
 
Only if dos filemode = yes

By the way, this whole "issue" is not a new one.  I set up this same
scenario last night on an old Linux Mandrake 8 box running Samba 2.2.7a
and the behavior was exactly the same.

Tom Schaefer