[Samba] RE: still ACL bug in 3.0.14a

Tue Apr 19 20:48:33 GMT 2005

I've been messing with it some more.  Yeah, you can take ACL's out of
the picture.  It basically boils down to in UNIX, even if the owner of
the file does not have write access, if the group does have write access
and you are a member of the group you can write to the file.

With Samba, at least by default, you can't.  Its like Peter is saying,
Samba seems to mark the file as read only since the owner doesn't have
write access and that is that.  It doesn't matter if the file actually
is writeable by me due to my group membership.

Now I don't know if this is by design, and/or exactly how it can be
finessed into behaving differently via some of those other directives
such as "store dos attributes" and what not.  But what I can say is that
to me nothing seems to have changed as far as all this goes between
3.0.11 and 3.0.14a.  I've done some testing of this matter today on both
versions.

Peter,  Take a look of this little session log I made a few minutes ago
and see if this basically presents what you are saying...

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\Documents and Settings\schaefert.UMSL-USERS>cd \

C:\>ssh -l schaefer stercus
schaefer at stercus's password:
Last login: Tue Apr 19 15:15:41 2005 from medusa.umsl.edu
Sun Microsystems Inc.   SunOS 5.8       Generic February 2000

schaefer at stercus:~ bash$ su -
Password:
Sun Microsystems Inc.   SunOS 5.8       Generic February 2000
You have new mail.
# bash

root at stercus:/ bash# cd ~schaefer

root at stercus:/accounts/staff/schaefer bash# mkdir peter

root at stercus:/accounts/staff/schaefer bash# cd peter

root at stercus:/accounts/staff/schaefer/peter bash# echo $TERM
cygwin

root at stercus:/accounts/staff/schaefer/peter bash# export TERM=vt100

root at stercus:/accounts/staff/schaefer/peter bash# echo "some text" >
newfile.txt

root at stercus:/accounts/staff/schaefer/peter bash# ls -l
total 2
-rw-r--r--   1 root     other         10 Apr 19  2005 newfile.txt

root at stercus:/accounts/staff/schaefer/peter bash# id schaefer
uid=241(schaefer) gid=60003(cfusion)

root at stercus:/accounts/staff/schaefer/peter bash# chgrp 60003
newfile.txt

root at stercus:/accounts/staff/schaefer/peter bash# chmod 060 newfile.txt

root at stercus:/accounts/staff/schaefer/peter bash# ls -l
total 2
----rw----   1 root     cfusion       10 Apr 19  2005 newfile.txt

root at stercus:/accounts/staff/schaefer/peter bash# ls -la
total 36
drwxr-xr-x   2 root     other        512 Apr 19  2005 ./
drwx--x--x  84 schaefer staff      16384 Apr 19  2005 ../
----rw----   1 root     cfusion       10 Apr 19  2005 newfile.txt

root at stercus:/accounts/staff/schaefer/peter bash# cat newfile.txt
some text

root at stercus:/accounts/staff/schaefer/peter bash# exit
exit
# exit

schaefer at stercus:~ bash$ export TERM=vt100

schaefer at stercus:~ bash$ cd peter

schaefer at stercus:~/peter bash$ ls -al
total 36
drwxr-xr-x   2 root     other        512 Apr 19  2005 ./
drwx--x--x  84 schaefer staff      16384 Apr 19  2005 ../
----rw----   1 root     cfusion       10 Apr 19  2005 newfile.txt

schaefer at stercus:~/peter bash$ echo "In UNIX I can write to newfile.txt
via the
group permission even though the write bit is not set for the owner" >>
newfile.
txt

schaefer at stercus:~/peter bash$ cat newfile.txt
some text
In UNIX I can write to newfile.txt via the group permission even though
the writ
e bit is not set for the owner

schaefer at stercus:~/peter bash$ id
uid=241(schaefer) gid=60003(cfusion)

schaefer at stercus:~/peter bash$ exit
logout
Connection to stercus closed.

C:\>net use * \\stercus\schaefer
Drive I: is now connected to \\stercus\schaefer.

The command completed successfully.

C:\>i:

I:\>cd peter

I:\peter>dir
 Volume in drive I is schaefer
 Volume Serial Number is 16CF-28CD

 Directory of I:\peter

04/19/2005  03:29p      <DIR>          .
04/19/2005  03:27p      <DIR>          ..
04/19/2005  03:31p                 121 newfile.txt
               1 File(s)            121 bytes
               2 Dir(s)  26,087,165,952 bytes free

I:\peter>echo "in windows, i can't write to the file" >> newfile.txt
Access is denied.

-----Original Message-----
From: Peter Kruse [mailto:pk at q-leap.com] 
Sent: Tuesday, April 19, 2005 12:09 PM
To: Schaefer Jr, Thomas R.
Cc: jra at samba.org; samba at lists.samba.org
Subject: Re: still ACL bug in 3.0.14a

Hello,

thanks, I just added a comment to 
https://bugzilla.samba.org/show_bug.cgi?id=2619 that shows my 
recent findings.  It looks like not directly related to ACLs, 
but more with "store dos attributes".  I still have the feeling 
that the behaviour of samba is somewhat not what you'd expect.

Regards,

	Peter

Tom Schaefer wrote:
> Hello,
> 
> I've kind of been hanging with Peter on this whole issue so didn't 
> want to just abandon him when Jeremy issued the Solaris patch that 
> fixed things for me.
> 
> I went and took a hard look at bug report 2619 that Peter filed and 
> tried to duplicate it.  He is doing ACLs on specific files, not 
> directories as I was.  When specifically following Peter's 
bug report, 
> I CAN duplicate the bug Peter found under Solaris even with the all 
> inclusive force group/Solaris patch Jeremy issued yesterday 
installed.  
> I put the new patch on the Linux box, and as Peter is saying, the 
> problem is still there as well.  I noticed Jeremy requesting level 10 
> debug logs on the bug tracking page.  I'll send some as soon as I can.
> 
> Tom Schaefer
> 
> On Tue, 19 Apr 2005 09:45:46 +0200
> Peter Kruse <pk at q-leap.com> wrote:
> 
> 
>>Hello again,
>>
>>Jeremy Allison wrote:
>>
>>>On Mon, Apr 18, 2005 at 06:35:12PM +0200, Peter Kruse wrote:
>>>
>>>
>>>>bad news, my problem is not fixed with 3.0.14a
>>>
>>>
>>>The log file helped. Try this patch (applies against
>>>raw 3.0.14a). Problem was Solaris was returning 2 in a
>>>place I expected a 1....
>>>
>>
>>tried it, makes no difference here.  I'm neither using "force group" 
>>nor using Solaris.  Sorry to confuse you, there are probably two 
>>different problems in the same thread, although the subject is valid 
>>for both. But as the Solaris issue seems to be resolved, maybe you 
>>could have a look at my bug report: 
>>https://bugzilla.samba.org/show_bug.cgi?id=2619
>>The bug report includes exact instructions how to reproduce it. I get 
>>the impression that the acl implementation is wrong.  It looks to me 
>>that if any user doesn't have write permission then the group 
settings 
>>are ignored. Jeremy, if you create such a file, do you get correct 
>>behaviour?
>>
>>Thx,
>>
>>	Peter
>>--
>>To unsubscribe from this list go to the following URL and read the
>>instructions:  https://lists.samba.org/mailman/listinfo/samba
>>