samba - Sep 2006 - Windows Application Overriding Samba Settings

I have just encountered a strange situation. A new version of a Windows 
application that I use was just released. Unlike previous versions of 
this application, when it writes data to my Samba share, it is setting 
permissions to be 777 on all files and folders. In contrast, previous 
versions of this application set permissions to be 2750 as I specify in 
the "share definition" in my smb.conf file.

In smb.conf, in the share definition I specify:

directory mask = 0750
create mask = 0750

My understanding is that this should LIMIT the maximum permissions that 
can be set for a file or folder created by Windows or a Windows 
application. The file or folder should never be group writable, or even 
accessible by "others".

In addition, I have also played with specifying the following options:

force directory mode = 2040
force create mode = 2040

Until this new version of the Windows application came out, I never had 
any issues. ANY folder or file created by the application always had the 
same permissions:  2750 or 570 (respectively)

But NOW The Windows application seems to be completely getting around 
the limits that I imposed with Samba and Linux. All files and folders 
are getting set as: 0777

I even have the root directory of the share (in which files and folders 
are getting created) set to SGID -- yet Windows is managing to override 
this and is not preserving the SGID on new folders.

Does anybody have a clue what's going on here? How can Windows or a 
Windows Application override my Linux and Samba settings? And is there 
anything I can do about it?

FYI...

In this case I am running Samba 3.0.13.  The Windows version is XP SP2. 
Please don't suggest that I upgrade to Samba 3.0.2x (unless you know 
that it specifically solves this problem). That is not an option at the 
moment.

Thanks in advance for the help.

Andy Liebman

Oops, sorry. I had a typo in my posting. I wrote:

Until this new version of the Windows application came out, I never had 
any issues. ANY folder or file created by the application always had 
the same permissions: 2750 or 570 (respectively)

I should have written:

Until this new version of the Windows application came out, I never had 
any issues. ANY folder or file created by the application always had 
the same permissions: 2750 or 750 (respectively)

I switched a 7 and a 5.

Andy Liebman
________________________________________________________________________
Check out the new AOL.  Most comprehensive set of free safety and 
security tools, free access to millions of high-quality videos from 
across the web, free AOL Mail and more.

> directory mask = 0750
> create mask = 0750
> My understanding is that this should LIMIT the maximum permissions
> that can be set for a file or folder created by Windows or a Windows 
> application.
AFAIK, these options only set the default permissions, a program can
still change them if it wants.
> In addition, I have also played with specifying the following options:
> force directory mode = 2040
> force create mode = 2040
Again, these force the permissions to a certain value when creating a
file, but they don't stop the permissions from being changed once the
file exists.
> But NOW The Windows application seems to be completely getting around 
> the limits that I imposed with Samba and Linux. All files and folders 
> are getting set as: 0777
There are two things that could be happening - it's possible that the
attributes are being mapped to UNIX permissions (so if the program sets
the archive bit, that's translated to the execute permission) or more
likely, the program is checking which users have access to the file and
is granting them all access (similar to what would happen if you
right-click on a file, go to the Security tab and grant all users
access there.)

I'm not sure of a way around this, but if there is one I'm sure
it'll
involve restricting the changing of permissions on files that already
exist (I'm pretty sure there are options related to this, check out the
smb.conf manpage.)

Cheers,
Adam.