Bug 4956 - DOS FILEMODE requires ownership for certain file operations
DOS FILEMODE requires ownership for certain file operations
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.22
x86 Windows XP
: P3 critical
: none
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on: 5202
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-06 14:25 UTC by rvjcallanan
Modified: 2013-12-27 14:58 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rvjcallanan 2007-09-06 14:25:38 UTC
I have used DOS FILEMODE = YES successfully and have verified correct operation by manually performing file operations using Windows explorer.

I have system, hidden, archive and read-only bits all mapped
My Linux platform is Ubuntu Server Edition 6.06 LTS.
I do *not* use extended attributes *nor* do I have ACLs enabled.

On closer inspection, I noticed that certain file operations produce ACCESS DENIED messages if the target files/directories are *not* owned by the logged on user. The bug is most likely to happen with XCOPY or when logging off with a non-mandatory roaming profile.

I am unable to update to latest Samba release but have not found a bug fix since 3.0.22 so I assume it is still there.

This is a serious bug as the whole point of DOS FILEMODE is to avoid the necessity for ownership.
Comment 1 Andrew Bartlett 2007-09-06 17:53:26 UTC
This has nothing to do with ntlm_auth.
Comment 2 rvjcallanan 2007-09-06 18:10:41 UTC
I have just isolated the *definite* cause of this bug.

On further investigation, I noticed that the problem related to the archive bit which is of course mapped to the owner execute bit. I do understand that DOS attribute mappings will not work for directories. But then why does the problem only happen when the logged on user is *not* the owner?

It seems that in DOS FILEMODE, when a windows client app attempts to set a *directory* archive bit, Samba just pretends the operation is successful even thought the archive bit is never actually set. However, if the user is NOT the owner then an ACCESS DENIED error is generated.

This is obviously a bug, albeit a very subtle one but it does cause XCOPY to bomb out and Windows Profile Saving to Server to fail.

A bug fix for this is vital as many stable server distros running samba do *not* use extended attribute mappings by default.
Comment 3 rvjcallanan 2007-09-06 18:13:42 UTC
(In reply to comment #1)
> This has nothing to do with ntlm_auth.

Apologies, but I could not find a "Don't Know" option
Comment 4 Rob J. Epping 2007-09-10 09:43:19 UTC
As the cause of the issue is found, this is me too.

I have this issue on a Debian etch server with samba 3.0.24-6etch4 and on a Debian etch server with my own backport version 3.0.25a-1~mc.1

BTW: I would guess this is an nmbd issue (I'm no allowed to change)
Comment 5 Rob J. Epping 2007-09-10 09:45:33 UTC
(In reply to comment #4)

> BTW: I would guess this is an nmbd issue (I'm no allowed to change)

Whoopps, not nmbd but smbd which is not selectable :(
Comment 6 Gerald (Jerry) Carter 2007-09-10 10:14:14 UTC
I think is by design, but maybe the design choice should be revisited.
Jeremy?
Comment 7 Rob J. Epping 2007-09-10 10:26:46 UTC
(In reply to comment #6)
> I think is by design, but maybe the design choice should be revisited.
> Jeremy?

When this is by design, then why do windows explorer and xcopy respond different?

Copying c:/dir/sub/file to //samba/share with xcopy (xcopy /s c:\sub \\samba\share) gives ACCESS DENIED, drag c:/dir and drop on //samba/share works :(
Comment 8 rvjcallanan 2007-09-10 12:10:31 UTC
(In reply to comment #6)
> I think is by design, but maybe the design choice should be revisited.
> Jeremy?

If by design, then why does it work okay for files? My understanding is that DOS FILE MODE is supposed to mean that, if the user has write access to file or folder, then he can modify file or folder attributes and ownership sould not enter into the equation. 

Comment 9 rvjcallanan 2007-09-10 12:14:55 UTC
> When this is by design, then why do windows explorer and xcopy respond
> different?

Actually, this may be a misperception. If you try to change directory archive bit in explorer, you will get an access denied message if you are not the owner. I think what happens with XCOPY and User-Profile Saving operations is that they try to change the archive bit in a given folder and the ACCESS DENIED error causes the entire operation to bomb out.
Comment 10 SATOH Fumiyasu 2008-07-03 02:41:38 UTC
I think this bug can be fixed by the patch in bug #5202 I posted.
Comment 11 Björn Jacke 2009-09-17 15:52:50 UTC
can one of you confirm that this is fixed in recent samba releases?
Comment 12 Björn Jacke 2013-12-27 14:58:37 UTC
No Feedback from Fumiyasu and rvjcallanan. Closing this now hoping it's fixed.