samba - Apr 2006 - DOS/Windows Archive bits, and file ownership

Preamble:
I've done a lot of looking round news-group archives etc, and I haven't
found a definitive answer on this question:

My environment:
Clients are all Windows boxes.
Assume backup of the "share" is a Windows based client. It relies on
the DOS Archive bit to determine Diff/Incr backup selections. (User
Execute bit in Linux)

Goal: Allow users to "own" their files and allow for
"automagic"
modification of the archive bit by non-owners of the file when they
modify the file using the Windows application or by the backup
application.

Example:
Joe creates a file called "JoeFile.txt"
Joe is listed as the owner, but the group is "AdmGroup" for example.

Fred is also a member of "AdmGroup"
Thus, Fred can modify/delete/etc "JoeFile.txt"

The problem comes when we look at the archive bit. 
As above, Fred can modify "JoeFile.txt" even though he's not the
owner, but he can't change permissions and modify the archive bit.

Create mask on the share is: 770 (I know, 760 would be sufficient for just the
archive bit, but I'll take the system bit too, a long as I'm here...)
This will allow the owner to change the archive bits, but no-one else.

I believe I've tested, albeit a while back, the "dos filemode"
parameter too.
IIRC, it would allow you to manually change the archive bits, by going
and setting the properties directly - say via Windows Exploter.

It wouldn't, however, allow for the applications, at least for those
that I tested, to change the archive bits on files unless the user
doing the modifications was also the owner.

---
I have ways around this, by using "force user" for the whole share,
but this really seems like a brute-force way to do things. It also
makes it impossible to determine who really owns the files, and who is
killing us on space - which always happens.

Further, the force-user there are other reasons which I won't bore you
with, why I don't care for "force user."

---
So, is this a live-with-it, as-designed bug that I just have to work
around, or is there some more elegant solution that I've not
recognized yet? (Or, perhaps more likely, have I just missed something
really stupid that I'm doing wrong.)

If more details are required, I'll be glad to provide what's needed.

TIA!
Greg

On Thu, 2006-04-06 at 15:46 -0700, Greg Sloop wrote:
> Preamble:
> I've done a lot of looking round news-group archives etc, and I
haven't found a definitive answer on this question:
> 
> My environment:
> Clients are all Windows boxes.
> Assume backup of the "share" is a Windows based client. It relies
on
> the DOS Archive bit to determine Diff/Incr backup selections. (User
> Execute bit in Linux)
> 
> Goal: Allow users to "own" their files and allow for
"automagic"
> modification of the archive bit by non-owners of the file when they
> modify the file using the Windows application or by the backup
> application.
> 
> Example:
> Joe creates a file called "JoeFile.txt"
> Joe is listed as the owner, but the group is "AdmGroup" for
example.
> 
> Fred is also a member of "AdmGroup"
> Thus, Fred can modify/delete/etc "JoeFile.txt"
> 
> The problem comes when we look at the archive bit. 
> As above, Fred can modify "JoeFile.txt" even though he's not
the
> owner, but he can't change permissions and modify the archive bit.
> 
> Create mask on the share is: 770 (I know, 760 would be sufficient for just
the archive bit, but I'll take the system bit too, a long as I'm
here...)
> This will allow the owner to change the archive bits, but no-one else.
> 
> I believe I've tested, albeit a while back, the "dos
filemode" parameter too.
> IIRC, it would allow you to manually change the archive bits, by going
> and setting the properties directly - say via Windows Exploter.
> 
> It wouldn't, however, allow for the applications, at least for those
> that I tested, to change the archive bits on files unless the user
> doing the modifications was also the owner.
> 
> ---
> I have ways around this, by using "force user" for the whole
share,
> but this really seems like a brute-force way to do things. It also
> makes it impossible to determine who really owns the files, and who is
> killing us on space - which always happens.
> 
> Further, the force-user there are other reasons which I won't bore you
> with, why I don't care for "force user."
> 
> ---
> So, is this a live-with-it, as-designed bug that I just have to work
> around, or is there some more elegant solution that I've not
> recognized yet? (Or, perhaps more likely, have I just missed something
> really stupid that I'm doing wrong.)
> 
> If more details are required, I'll be glad to provide what's
needed.
----
I think 'create mask' would give you what you want.

see the details for its usage in the man page for smb.conf

Craig

Hi Greg,

If you want the DOS type attribute bits to be accurate, then your best bet is to
have an EA supporting file system on the server (Such as XFS) and tell Samba to
store the attributes in EA's vs trying
to map them to Linux attributes.

Per Mr. Allison's suggestion, I have added this to our global section
recently...

;New things global to all shares for ACL support...
    map hidden = no
    map system = no
    map archive = no
    store dos attributes = yes

So that might play a part in what you are trying to do. If other details come to
mind, I will post again.

-- 
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

Remove the upper case letters NOSPAM to contact me directly.