chmod(2) / DOS Archive semantics

[John E. Malmberg]

Barry Dean writes:
> I have run up against a problem with "DOS Archive Bit" semantics in SAMBA
2.0.7.

Just my personal opinion:

For OpenVMS, one of the file attributes is the backup date.  For SAMBA, If
the file has never been backed up, I set the appropriate bit in a wrapper to
stat() so the file is reported with the A bit set.

Manipulating this backup date is not something that most users do.  So I
have implemented this as a display only function.  Any attempt to manipulate
the Archive bit from a SAMBA client is simply ignored.

I have noticed that the way that different UNIX like systems handle the
recording of if a file has been backed up is different.

If anything is done in this area to change the behavior of how SAMBA handles
the Archive Bit, I think that most users and system administrators would
prefer that it track the true backup state, even if it means losing the
ability of the manipulate it from the client with out otherwise changing the
file.

> We have directories that groups write to. If you have a group bedrock,
with
> users fred and barney you may have files thus:
>
> -rwxrw-r--   1 fred     bedrock     1383 Aug 23 15:15 fred.html
> -rwxrw-r--   1 barney   bedrock     1437 Aug 23 14:18 barney.html
>
> If fred tries to change DOS archive (owner x on Unix) on fred.html,
> fine.
>
> BUT if fred tries to change DOS archive on barney.html it fails, of
> course - from the manpage chmod(2):

IMHO: This is expected and desired behavior, consistent with the host
operating system's security policy.  Changing this could cause problems when
the user complains that their file did not get backed up because someone
cleared the Archive bit.

> > The effective user ID of the process must match the owner of
> > the  file or the process must have the appropriate privilege
> > to change the mode of a file.
>
> Samba is running as fred at this point, so it fails.
>
>
> Is anyone working on this?

I am not part of the SAMBA team, just an independent working to get it
running on the OpenVMS platform.

> This causes me a problem as I have nearly 400 web authors publishing
> pages to my samba shares. They have been told to use Dreamweaver, which
> tries to do this when publishing a file:
>
> 1 set DOS archive on
> 2 truncate file to 0 bytes
> 3 write new file contents
> 4 set time on destination file to same as source file
> 5 set DOS archive off

On a true Microsoft system, I would expect steps 2 or 3 to cause the archive
bit to be set.  By turning the DOS archive bit off, the software is
effectively setting the file not to be backed up.

This also means that the software never has a reason to do step 1.

This can cause problems on a Microsoft NT network when it is discovered that
files modified by Dreamweaver are not backed up, and should be reported as a
serious bug to whoever supports the product.

Deliberately and automatically manipulating the backup state of a file is a
major data integrity problem.  Especially when you set files to not be
backed up.

With out a way for SAMBA (generically) to accurately report the true backup
state of a file, it would be difficult to properly implement the display of
the Archive bit.  I suspect that the closest way for SAMBA to accomodate
this would be to make sure that it sets the archive bit anytime it either
truncates or modifies a file.

Just to make sure that we are clear on this, having the DOS archive bit set,
means that the the file has not been backed up.  A DOS / Windows based
backup program should clear the backup bit.

It looks like that if SAMBA fixes the ARCHIVE bit to actually mean something
like it does on a true NT server, that it could cause you to lose data, as
the files produced by Dreamweaver would not be backed up.  I would be very
unhappy if I restored a backup on a web server and was missing all the files
that Dreamweaver had modified.  At some sites, this can cause a person to
get fired.

Unless you have your explaination of how the ARCHIVE bit is manipulated by
Dreamweaver reversed, and then the prefered solution would be for SAMBA to
make sure that the Archive bit is set when ever it modifies a file, and not
override the normal operating system security.

The behavior of the DOS attributes for files can be better mapped on some
filesystems then on others.  I would prefer that they more closely reflect
the true state of the file in these cases than the simulations that is
currently present.

I am currently only looking at the 2.0.6 code, so I do not know if this has
been addressed in more current work.

-John
wb8tyw at qsl.network