Bug#532856: umask settings overridden by Mac OS X 10.5 (Leopard) clients
Josip Rodin
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.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve Langasek
> 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/
slan...@ubuntu.com vor...@debian.org
Josip Rodin
> 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.
--
Christian Perrier
> 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.
Josip Rodin
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).
Josip Rodin
> Closing as this is not a bug but a configuration tuning.
Sorry, what? I don't see such an explanation in the bug log.
Two people said "unix extensions = no" would work around the issue.
Nobody provided an actual solution to the issue.
> 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).
Mathieu Parent
Le jeu. 28 juin 2018 à 03:00, Josip Rodin <j...@debbugs.entuzijast.net> a écrit :
>
> On Mon, Jun 18, 2018 at 09:51:03PM +0000, Debian Bug Tracking System wrote:
> > Closing as this is not a bug but a configuration tuning.
>
> Sorry, what? I don't see such an explanation in the bug log.
> Two people said "unix extensions = no" would work around the issue.
> Nobody provided an actual solution to the issue.
"chmod" (an UNIX extension), and nothing prevents it server-side.
> Nobody responded to the part where I said:
>
> > 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).
> Can you?
The "create mask" doesn't impact the chmod UNIX extension. And nothing
prevents this chmod except "unix extensions = no" or insufficient
perms (i.e. local UNIX permissions as if you runt chmod locally).
Regards
--
Mathieu Parent
Josip Rodin
> The "create mask" doesn't impact the chmod UNIX extension.
the option is called "do X", and fails to do X in some opaque circumstances,
how is that not a bug? At the very very least, it needs to be explained
somewhere. Last I checked, there was nothing in the smb.conf manual to
indicate that any of this would happen. The existence of a chmod extension
isn't even mentioned. (As I said before.)
On a more general note, I would recommend triaging user bug reports when you
are available to actually try to understand what users are saying. Ignoring
information provided and repeating the same question all over again is
unhelpful at best.
Andrew Bartlett
While this goes against general Debian practice, these bug reports are
really not a good place to discuss general issues with Samba.
There are good, upstream e-mail lists with a much larger peer user base
and monitored by full-time Samba developers. Likewise the upstream
bugzilla tracks issues for the project as a whole, and is actively
reponded to (mostly) by Samba Team members.
Finally, the Debian Samba project has a fairly strict policy of not
carrying local patches, so any change has to go via the above in any
case.
Sorry,
Andrew Bartlett
--
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT
https://catalyst.net.nz/services/samba
Josip Rodin
> > How does that make sense? If the option is called "do X", and fails to
> > do X in some opaque circumstances, how is that not a bug? At the very
> > very least, it needs to be explained somewhere. Last I checked, there
> > was nothing in the smb.conf manual to indicate that any of this would
> > happen. The existence of a chmod extension isn't even mentioned. (As I
> > said before.)
> >
> > On a more general note, I would recommend triaging user bug reports when you
> > are available to actually try to understand what users are saying. Ignoring
> > information provided and repeating the same question all over again is
> > unhelpful at best.
>
> Honestly, this really isn't the place.
>
> While this goes against general Debian practice, these bug reports are
> really not a good place to discuss general issues with Samba.
universally common practices of the Debian bug tracking system.
The Debian social contract doesn't go into that much detail, to explicitly
require keeping bugs open because they exist in practice -- but common sense
and decades of precedent do.
Or is this some new thing that we're now doing, am I that much out of
the loop?
Andrew Bartlett
> On Mon, Jul 02, 2018 at 09:41:39AM +1200, Andrew Bartlett wrote:
> > > How does that make sense? If the option is called "do X", and fails to
> > > do X in some opaque circumstances, how is that not a bug? At the very
> > > very least, it needs to be explained somewhere. Last I checked, there
> > > was nothing in the smb.conf manual to indicate that any of this would
> > > happen. The existence of a chmod extension isn't even mentioned. (As I
> > > said before.)
> > >
> > > On a more general note, I would recommend triaging user bug reports when you
> > > are available to actually try to understand what users are saying. Ignoring
> > > information provided and repeating the same question all over again is
> > > unhelpful at best.
> >
> > Honestly, this really isn't the place.
> >
> > While this goes against general Debian practice, these bug reports are
> > really not a good place to discuss general issues with Samba.
>
> It's unreasonable to have a Debian package that doesn't respect the
> universally common practices of the Debian bug tracking system.
the tasks you suggest as well as the other elements of maintaining the
package (it is marked help wanted and has been for years).
> The Debian social contract doesn't go into that much detail, to explicitly
> require keeping bugs open because they exist in practice -- but common sense
> and decades of precedent do.
packaging bugs. I'll let others argue as to if validated but upstream
bugs should be left open, but debatable configuration discussions have
no useful place here.
Upstream (non-packaging) bugs filed here at best have to be copied into
Samba's bugzilla before any progress can be made and the lossy nature
of that just makes work for everyone.
> Or is this some new thing that we're now doing, am I that much out of
> the loop?
packagers from the overwhelming load from time to time.
Finally, debates, even meta debates, about unsupported and ancient
Samba and MacOS versions are simply not productive.
Josip Rodin
> We simply don't have the resources to manage the tasks you suggest
just keep an existing bug open. That change alone actually conserves
resources. Sending a message to the control bot to tag it upstream and
perhaps mark it wontfix or a custom tag called triaged or something like
that - doesn't sound particularly more taxing compared to closing.
> Upstream (non-packaging) bugs filed here at best have to be copied into
> Samba's bugzilla before any progress can be made and the lossy nature
> of that just makes work for everyone.
the chaff and forward upstream stuff upstream.
> Finally, debates, even meta debates, about unsupported and ancient
> Samba and MacOS versions are simply not productive.
be fixed - I've reverted to arguing simply that if there's a piece of
functionality (Unix extensions) in the software, the documentation for the
software should mention its basic characteristics, esp. those that have been
known to cause annoying behavior in practice.
It would be akin to having the Apache documentation describe its HTTPS
support with two sentences in a manual, and have nothing else whatsoever
(yet it ships e.g. /etc/apache2/mods-available/ssl.conf with a fair bit
of info, and there's other docs too).
Andrew Bartlett
> Yet, this isn't one, as I've long given up on expecting that upgrade path to
> be fixed - I've reverted to arguing simply that if there's a piece of
> functionality (Unix extensions) in the software, the documentation for the
> software should mention its basic characteristics, esp. those that have been
> known to cause annoying behavior in practice.
>
> It would be akin to having the Apache documentation describe its HTTPS
> support with two sentences in a manual, and have nothing else whatsoever
> (yet it ships e.g. /etc/apache2/mods-available/ssl.conf with a fair bit
> of info, and there's other docs too).
won't achieve your aims.
Sorry,
Thomas Goirand
> The Debian social contract doesn't go into that much detail, to explicitly
> require keeping bugs open because they exist in practice -- but common sense
> and decades of precedent do.
if they are not actionable. Bugs are reminders for the maintainers of
what they should do. If they can't do anything, then it goes on the way
to do useful things, and it is best if they can be closed.
Cheers,
Thomas Goirand (zigo)
P.S: I don't know about this particular bug, just reacting on your
sentence above.
Henrique de Moraes Holschuh
> I very much don't agree with the above. It is useless to keep bugs open
> if they are not actionable. Bugs are reminders for the maintainers of
> what they should do. If they can't do anything, then it goes on the way
> to do useful things, and it is best if they can be closed.
known, it is still active, and what has been discussed about it. This
would be more useful if people were better at searching for open issues
in the BTS before complaining, but still...
Anyway, since it is a fact that non-actionable bugs can be a distraction
for the maintainer, we have a middle-ground: we have tags like
"wontfix", not to mention usertags, and the BTS allows one to filter out
listing by tags easily enough. It might be nice to enhance it to allow
one to set a cookie with personal default filters, though.
Anyway (and this is a generic response, not particular to this bug), if
one is going to close an unfixed bug because it is unactionable, it
would be rather helpful if that bug is tagged "wontfix", just like if it
were to be kept open.
--
Henrique Holschuh