Bug#525321: [Pkg-samba-maint] Bug#525321: samba: force create mode option no longer works
Quoting Nick Nobody (m...@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. 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? signature.asc Description: Digital signature
Bug#525321: [Pkg-samba-maint] Bug#525321: samba: force create mode option no longer works
On Fri, 2009-04-24 at 12:04 +0200, Christian Perrier wrote:
Quoting Nick Nobody (m...@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= and that doesn't help.
Another weird thing I've noticed (which is not in 3.0.24-6etch10):
nikos...@kubuntubox:~$ touch {copy,move}test; chmod 777 {copy,move}test
nikos...@kubuntubox:~$ cp copytest /mnt/smb/archives/
nikos...@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
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?
Thanks for your patience,
nick
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525321: [Pkg-samba-maint] Bug#525321: Bug#525321: samba: force create mode option no longer works
Nick Nobody wrote:
On Fri, 2009-04-24 at 12:04 +0200, Christian Perrier wrote:
Quoting Nick Nobody (m...@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= and that doesn't help.
Another weird thing I've noticed (which is not in 3.0.24-6etch10):
nikos...@kubuntubox:~$ touch {copy,move}test; chmod 777 {copy,move}test
nikos...@kubuntubox:~$ cp copytest /mnt/smb/archives/
nikos...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525321: [Pkg-samba-maint] Bug#525321: Bug#525321: samba: force create mode option no longer works
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 (m...@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= and that doesn't help.
Another weird thing I've noticed (which is not in 3.0.24-6etch10):
nikos...@kubuntubox:~$ touch {copy,move}test; chmod 777 {copy,move}test
nikos...@kubuntubox:~$ cp copytest /mnt/smb/archives/
nikos...@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
nikos...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525321: [Pkg-samba-maint] Bug#525321: Bug#525321: samba: force create mode option no longer works
On Fri, Apr 24, 2009 at 10:30:15PM +0200, Luk Claes wrote:
Both the server and the client have a default umask of 0022 and I've
tried mounting the share with umask= and that doesn't help.
Another weird thing I've noticed (which is not in 3.0.24-6etch10):
nikos...@kubuntubox:~$ touch {copy,move}test; chmod 777 {copy,move}test
nikos...@kubuntubox:~$ cp copytest /mnt/smb/archives/
nikos...@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.
More precisely, the cp command calls:
open(foo, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open(bar, O_WRONLY|O_TRUNC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
read(3, , 4096) = 0
close(4)= 0
close(3)= 0
and the mv command calls:
rename(foo, /home/vorlon/baz) = -1 EXDEV (Invalid cross-device link)
unlink(/home/vorlon/baz) = -1 ENOENT (No such file or directory)
open(foo, O_RDONLY|O_NOFOLLOW)= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open(/home/vorlon/baz, O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
read(3, , 4096) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fchmod(4, 0100644) = 0
^^
close(4)= 0
close(3)= 0
So when you have Unix extensions enabled, the chmod operation is honored,
overriding any defaults set on open by 'force create mode'.
If you don't want Unix modes on the client to be honored, you should disable
unix extensions.
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?
Both create a file, but in one case the initial perms are overridden.
So if the only concern is the permissions when using 'mv', I would say this
is not a bug.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525321: [Pkg-samba-maint] Bug#525321: Bug#525321: samba: force create mode option no longer works
On Fri, 2009-04-24 at 16:47 -0700, Steve Langasek wrote: So when you have Unix extensions enabled, the chmod operation is honored, overriding any defaults set on open by 'force create mode'. If you don't want Unix modes on the client to be honored, you should disable unix extensions. That makes sense, I recall reading that unix extensions (or something that has to do with that setting) for the etch version of samba was broken (it also explains some errors I'd get when doing certain file operations). I disabled unix extensions with version 2:3.2.5-4lenny2 and sure enough, it works. Thanks for your help and sorry for wasting your time, nick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525321: samba: force create mode option no longer works
Package: samba Version: 2:3.2.5-4lenny2 Severity: normal After upgrading to lenny (from etch) it seems that the force create mode option no longer works. However, if I downgrade samba to 3.0.24-6etch10 the option works as it should. Here's an example: nikos...@kubuntubox:~$ touch testfile; chmod 600 testfile nikos...@kubuntubox:~$ mv testfile /mnt/smb/archives/ teh-server:~# ls -l /mnt/md1/archives/testfile -rw--- 1 samba samba 0 2009-04-23 11:23 /mnt/md1/archives/testfile When using the older version of samba, the permissions of that file would have been -rw-rw-r-- which is consistent with what I have in my config file. The relevant bits from my /etc/samba/smb.conf: [global] snip force user = samba force group = samba directory mask = 0775 create mask = 0664 force create mode = 0664 force directory mode = 0775 browseable = yes guest ok = yes -- System Information: Debian Release: 5.0.1 APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages samba depends on: ii adduser 3.110add and remove users and groups ii debconf [debcon 1.5.24 Debian configuration management sy ii libacl1 2.2.47-2 Access control list shared library ii libattr11:2.4.43-2 Extended attribute shared library ii libc6 2.7-18 GNU C Library: Shared libraries ii libcomerr2 1.41.3-1 common error description library ii libcups21.3.8-1lenny5Common UNIX Printing System(tm) - ii libgnutls26 2.4.2-6+lenny1 the GNU TLS library - runtime libr ii libkrb531.6.dfsg.4~beta1-5lenny1 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries ii libpam-modules 1.0.1-5+lenny1 Pluggable Authentication Modules f ii libpam-runtime 1.0.1-5+lenny1 Runtime support for the PAM librar ii libpam0g1.0.1-5+lenny1 Pluggable Authentication Modules l ii libpopt01.14-4 lib for parsing cmdline parameters ii libtalloc1 1.2.0~git20080616-1 hierarchical pool based memory all ii libwbclient02:3.2.5-4lenny2 client library for interfacing wit ii logrotate 3.7.1-5 Log rotation utility ii lsb-base3.2-20 Linux Standard Base 3.2 init scrip ii procps 1:3.2.7-11 /proc file system utilities ii samba-common2:3.2.5-4lenny2 Samba common files used by both th ii update-inetd4.31 inetd configuration file updater ii zlib1g 1:1.2.3.3.dfsg-12compression library - runtime samba recommends no packages. Versions of packages samba suggests: pn ldb-tools none (no description available) ii openbsd-inetd [inet-superse 0.20080125-2 The OpenBSD Internet Superserver pn smbldap-tools none (no description available) -- debconf information: samba/run_mode: daemons samba/tdbsam: false samba/generate_smbpasswd: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525321: [Pkg-samba-maint] Bug#525321: samba: force create mode option no longer works
Quoting m...@nikosapi.org (m...@nikosapi.org): Package: samba Version: 2:3.2.5-4lenny2 Severity: normal After upgrading to lenny (from etch) it seems that the force create mode option no longer works. However, if I downgrade samba to 3.0.24-6etch10 the option works as it should. Here's an example: nikos...@kubuntubox:~$ touch testfile; chmod 600 testfile nikos...@kubuntubox:~$ mv testfile /mnt/smb/archives/ teh-server:~# ls -l /mnt/md1/archives/testfile -rw--- 1 samba samba 0 2009-04-23 11:23 /mnt/md1/archives/testfile When using the older version of samba, the permissions of that file would have been -rw-rw-r-- which is consistent with what I have in my config file. 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. signature.asc Description: Digital signature
Bug#525321: [Pkg-samba-maint] Bug#525321: samba: force create mode option no longer works
On Thu, 2009-04-23 at 23:47 +0200, Christian Perrier wrote: Quoting m...@nikosapi.org (m...@nikosapi.org): Package: samba Version: 2:3.2.5-4lenny2 Severity: normal After upgrading to lenny (from etch) it seems that the force create mode option no longer works. However, if I downgrade samba to 3.0.24-6etch10 the option works as it should. Here's an example: nikos...@kubuntubox:~$ touch testfile; chmod 600 testfile nikos...@kubuntubox:~$ mv testfile /mnt/smb/archives/ teh-server:~# ls -l /mnt/md1/archives/testfile -rw--- 1 samba samba 0 2009-04-23 11:23 /mnt/md1/archives/testfile When using the older version of samba, the permissions of that file would have been -rw-rw-r-- which is consistent with what I have in my config file. 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. 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? An example should clear this up: 1. File's original mode:-rwx---rw- (0706) 2. create mask: -rw-rw-r-- (0664) 3. Resulting mode (AND of 1,2): -rwr-- (0604) 4. force create mode: -rw-rw (0660) 5. Final mode (OR of 3,4): -rw-rw-r-- (0664) Am I wrong in thinking that this is how it's supposed to work? nick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
