Debian Bug report logs - #532856
umask settings overridden by Mac OS X 10.5 (Leopard) clients

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Josip Rodin <joy@debbugs.entuzijast.net>

To: submit@bugs.debian.org

Subject: umask settings overridden by Mac OS X 10.5 (Leopard) clients

Date: Fri, 12 Jun 2009 11:27:08 +0200

Package: samba
Version: 2:3.2.5-4lenny2

Hi,

MacOS 10.5 (Leopard) users seem to have a NetBIOS client that by default
is able to completely override file and directory permissions on Samba
shares. I have the shares set up like this on the server smb.conf:

[Temp]
  path = /srv/Temp
  read only = No
  guest ok = No
  valid users = @users
  write list = @users
  force group = "users"
  create mask = 0775
  security mask = 0775
  force create mode = 0660
  directory mask = 2775
  directory security mask = 2775
  force directory mode = 2771
  case sensitive = No
  inherit permissions = yes
  hide files = :2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/:2eTemporaryItems/Thumbs.db/

This is my final result of experimentation - before, with Samba 3.0,
we did not even have 'security mask', 'force create mode', 'directory
security mask', 'force directory mode', 'inherit permissions' - and
everything worked fine. Now after the upgrade to lenny on the Samba server,
it no longer does for this subset of users.

testparm says the following about that:

[Temp]
        path = /srv/Temp
        valid users = @users
        write list = @users
        force group = "users"
        read only = No
        create mask = 0775
        force create mode = 0660
        security mask = 0775
        directory mask = 02775
        force directory mode = 02771
        directory security mask = 02775
        inherit permissions = Yes
        case sensitive = No
        hide files = :2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/:2eTemporaryItems/Thumbs.db/

Windows XP and Linux clients create files (nearly) as prescribed, for example:

[joy@tokio:/srv/Temp]% smbclient //tokio/Temp
Enter joy's password: 
Domain=[IMAGO] OS=[Unix] Server=[Samba 3.2.5]
smb: \> dir
  .                                   D        0  Wed Jun 10 01:00:01 2009
  ..                                  D        0  Sun Jun  7 17:59:29 2009
  .DS_Store                          AH     6148  Tue Jun  9 11:54:06 2009

                65535 blocks of size 33553920. 4217 blocks available
smb: \> lcd /etc
smb: \> put motd
putting file motd as \motd (11,2 kb/s) (average 11,2 kb/s)
smb: \> mkdir foo
smb: \> exit
[joy@tokio:/srv/Temp]% ls -ld motd foo
drwxrwxr-x 2 joy users  6 2009-06-12 11:18 foo
-rwxrw-r-- 1 joy users 80 2009-06-12 11:15 motd

This is acceptable - I didn't get the setgid bit on directories, but that
would be icing on the cake, and I have 'force group' in effect anyway.
Mac OS X 10.4 'Tiger' clients seem to behave the same.

However, Mac OS X 10.5 'Leopard' users seem to have their default system
umask of 022 magically propagate into the Samba server, and then their dirs
become 0755 and files become either 0644 or even worse (sometimes o-r,
sometimes g-r,g+w!).

Only after we made those users to have umask 002 in their
/etc/launchd.conf files and rebooted them, did their new files start
getting the right permissions on these Samba shares. However, that is
just a workaround, judging by the description in smb.conf(5), the server
never should have let them apply their own umasks in the first place...

I've tried comparing debug logs between different clients at level 5, but
it's pretty hard to decipher much, because there's a fair bit of overhead,
and little in the way of explanation - what I did saw was many of these:

create_file: access_mask = 0x20001 file_attributes = 0x80,
share_access = 0x7, create_disposition = 0x1 create_options = 0x0
oplock_request = 0x0 root_dir_fid = 0x0, ea_list = 0x(nil), sd = 0x(nil),
fname = some/path/._filename.ai

...but then I have to convert these hexadecimal numbers into octal,
and I don't know exactly with what to combine the numbers so as to
get the mask meaning...

Please help. TIA.

-- 
     2. That which causes joy or happiness.

Message #10 received at 532856@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Josip Rodin <joy@debbugs.entuzijast.net>, 532856@bugs.debian.org

Subject: Re: Bug#532856: umask settings overridden by Mac OS X 10.5 (Leopard) clients

Date: Fri, 12 Jun 2009 09:42:56 -0700

On Fri, Jun 12, 2009 at 11:27:08AM +0200, Josip Rodin wrote:
> However, Mac OS X 10.5 'Leopard' users seem to have their default system
> umask of 022 magically propagate into the Samba server, and then their dirs
> become 0755 and files become either 0644 or even worse (sometimes o-r,
> sometimes g-r,g+w!).

> Only after we made those users to have umask 002 in their
> /etc/launchd.conf files and rebooted them, did their new files start
> getting the right permissions on these Samba shares. However, that is
> just a workaround, judging by the description in smb.conf(5), the server
> never should have let them apply their own umasks in the first place...

Is this affected if you set 'unix extensions = no' on the server?

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Message #15 received at 532856@bugs.debian.org (full text, mbox, reply):

From: Josip Rodin <joy@debbugs.entuzijast.net>

To: Steve Langasek <vorlon@debian.org>

Cc: 532856@bugs.debian.org

Subject: Re: Bug#532856: umask settings overridden by Mac OS X 10.5 (Leopard) clients

Date: Fri, 12 Jun 2009 21:28:19 +0200

On Fri, Jun 12, 2009 at 09:42:56AM -0700, Steve Langasek wrote:
> On Fri, Jun 12, 2009 at 11:27:08AM +0200, Josip Rodin wrote:
> > However, Mac OS X 10.5 'Leopard' users seem to have their default system
> > umask of 022 magically propagate into the Samba server, and then their dirs
> > become 0755 and files become either 0644 or even worse (sometimes o-r,
> > sometimes g-r,g+w!).
> 
> > Only after we made those users to have umask 002 in their
> > /etc/launchd.conf files and rebooted them, did their new files start
> > getting the right permissions on these Samba shares. However, that is
> > just a workaround, judging by the description in smb.conf(5), the server
> > never should have let them apply their own umasks in the first place...
> 
> Is this affected if you set 'unix extensions = no' on the server?

I'll be able to test that later, sorry, the clients are all down now (TGIF :)

After this hint, I've done a more precise google search, and it looks
like others have come across very similar problems before me, e.g.
http://discussions.apple.com/thread.jspa?messageID=7349655
http://bugs.contribs.org/show_bug.cgi?id=4164

At this point I'm completely dazzled by the amount of conflicting ACL
systems Samba is involved with :) one thing seems certain - it's pretty
confusing for us users.

-- 
     2. That which causes joy or happiness.

Message #20 received at 532856@bugs.debian.org (full text, mbox, reply):

From: Christian Perrier <Christian.Perrier@onera.fr>

To: Josip Rodin <joy@debbugs.entuzijast.net>, 532856@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>

Subject: Re: [Pkg-samba-maint] Bug#532856: umask settings overridden by Mac OS X 10.5 (Leopard) clients

Date: Sat, 13 Jun 2009 08:10:08 +0200

[Message part 1 (text/plain, inline)]

Quoting Josip Rodin (joy@debbugs.entuzijast.net):

> At this point I'm completely dazzled by the amount of conflicting ACL
> systems Samba is involved with :) one thing seems certain - it's pretty
> confusing for us users.


Correct. The main general problem behind this is that it's impossible
to entirely map NT ACLs to POSIX ACLs. Which is why vfs_acl_tdb is
being developed now.

From my understanding of Jeremy Allison's talk about it at SambaXP, if
you want a full implementation of ACLs, you'll want this VFS module. In
such case ACLs will be stored in a TDB file without trying to use the
filesystem's ACLs.

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 532856@bugs.debian.org (full text, mbox, reply):

From: Josip Rodin <joy@debbugs.entuzijast.net>

To: Christian Perrier <Christian.Perrier@onera.fr>

Cc: 532856@bugs.debian.org, Steve Langasek <vorlon@debian.org>

Subject: Re: [Pkg-samba-maint] Bug#532856: umask settings overridden by Mac OS X 10.5 (Leopard) clients

Date: Sat, 20 Jun 2009 13:16:55 +0200

On Sat, Jun 13, 2009 at 08:10:08AM +0200, Christian Perrier wrote:
> Quoting Josip Rodin (joy@debbugs.entuzijast.net):
> 
> > At this point I'm completely dazzled by the amount of conflicting ACL
> > systems Samba is involved with :) one thing seems certain - it's pretty
> > confusing for us users.
> 
> Correct. The main general problem behind this is that it's impossible
> to entirely map NT ACLs to POSIX ACLs. Which is why vfs_acl_tdb is
> being developed now.
> 
> From my understanding of Jeremy Allison's talk about it at SambaXP, if
> you want a full implementation of ACLs, you'll want this VFS module. In
> such case ACLs will be stored in a TDB file without trying to use the
> filesystem's ACLs.

I'm not sure how this applies as a solution to my problem, though. I had
specified all documented options that describe native Linux permission masks
to be applied on files on Samba shares. The daemon ignored this because of
another implicit option being in effect, one which contradicted those other,
explicit settings. That just doesn't make sense from a user standpoint,
regardless of the rationale. A proper bug fix would be to change the
behaviour of that new option to take into account the requirements set by
old options (better), or to fully document the impact of the new option and
make it explicit (worse, but still satisfactory).

-- 
     2. That which causes joy or happiness.

Message #32 received at 532856@bugs.debian.org (full text, mbox, reply):

From: Jelmer Vernooij <jelmer@samba.org>

To: 532856@bugs.debian.org

Subject: chmod() is not prohibited

Date: Sat, 25 Jan 2014 02:21:37 +0000

[Message part 1 (text/plain, inline)]

I suspect Mac OS X is doing an explicit chmod call to override the
permisions, which nothing in your configuration prohibits. The 'create
mask' is, as the name indicates, only applied when files are created.

Setting 'unix extensions = no' might help work around this issue.

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.