[Pkg-samba-maint] Bug#525321: Bug#525321: Bug#525321: samba: "force create mode" option no longer works

[Nick Nobody]

On Fri, 2009-04-24 at 22:30 +0200, Luk Claes wrote:
> Nick Nobody wrote:
> > On Fri, 2009-04-24 at 12:04 +0200, Christian Perrier wrote:
> >> Quoting Nick Nobody (me at nikosapi.org):
> >>
> >>>> What happens when you copy the file ?
> >>>>
> >>>> I see the same behaviour than the one you see, with 3.3.3. However,
> >>>> copying the file ends up with the right permissions.
> >>>>
> >>>> I'm not entirely sure that what you see is a bug, actually. After all,
> >>>> when moving a file, you expect permissions to remain as they are.
> >>>>
> >>>>
> >>> The same thing occurs even if I copy a file.
> >> It doesn't on my side. Copying a file ends up with the expected
> >> permissions.
> >>
> >> Which is why I assume that experiencing the problem with "mv" only is
> >> IMHO maybe not a bug.
> > 
> > If this is isn't a bug, then what's the point of the "force create mode"
> > option? Whether I'm copying or moving a file to the samba share, I'm
> > still *creating* a new file on the remote server. All newly created
> > files should at least have the same permissions as "force create mode".
> > 
> > This seems to be pretty clearly laid-out in the smb.conf man page:
> > 
> >     create mask (S)
> > 
> >     When a file is created, the necessary permissions are calculated
> >     according to the mapping from DOS modes to UNIX permissions, and
> >     the resulting UNIX mode is then bit-wise ´AND´ed with this
> >     parameter. This parameter may be thought of as a bit-wise MASK for
> >     the UNIX modes of a file. Any bit not set here will be removed from
> >     the modes set on a file when it is created.
> > 
> >     The default value of this parameter removes the group and other
> >     write and execute bits from the UNIX modes.
> > 
> >     Following this Samba will bit-wise ´OR´ the UNIX mode created from
> >     this parameter with the value of the force create mode parameter
> >     which is set to 000 by default.
> > 
> >>> I'm pretty sure this is a bug, in the smb.conf manpage it says that the
> >>> mode given to the "force create mode" gets OR'd with the file's
> >>> permissions. This guarantees that you'll always have at *least* whatever
> >>> "force create mode" is set to. The way I understand this is: "create
> >>> mask" strips away permissions and "force create mode" adds them, no?
> >>
> >> If I could reproduce the bug when copying a file, I would
> >> agree. However I am not..:-)
> >>
> >> Have you considered checking the "umask" settings which you're using?
> >>
> > 
> > Both the server and the client have a default umask of 0022 and I've
> > tried mounting the share with umask=0000 and that doesn't help.
> > 
> > Another weird thing I've noticed (which is not in 3.0.24-6etch10):
> > 
> > nikosapi at kubuntubox:~$ touch {copy,move}test; chmod 777 {copy,move}test
> > nikosapi at kubuntubox:~$ cp copytest /mnt/smb/archives/
> > nikosapi at kubuntubox:~$ mv movetest /mnt/smb/archives/
> > 
> > teh-server:~# ls -l /mnt/md1/archives/{copy,move}test
> > -rwxr-xr-x 1 samba samba 0 2009-04-24 15:41 /mnt/md1/archives/copytest
> > -rwxrwxrwx 1 samba samba 0 2009-04-24 15:40 /mnt/md1/archives/movetest
> 
> This is because a umask has no effect on a move operation, but it does 
> on a copy operation.
> 
> > Shouldn't the execute bits be wiped out by my "create mask" (0664)? And
> > why are the group and others' write bits being removed when copying?
> 
> I guess copying nor moving is seen as creating a file. What's the 
> behaviour if you save a new file on the share?
> 
> Cheers
> 
> Luk

nikosapi at kubuntubox:~$ touch /mnt/smb/archives/testfile

teh-server:~# ls -l /mnt/md1/archives/testfile 
-rw-r--r-- 1 samba samba 0 2009-04-24 16:30 /mnt/md1/archives/testfile

When using the older version (3.0.24-6etch10) I get the expected result:
-rw-rw-r-- 1 samba samba 0 2009-04-24 16:29 /mnt/md1/archives/testfile

nick