File Permission Suggestion

[John E. Malmberg]

On Fri, 10 Aug 2001, Tristan Ball wrote:

> John Malmberg wrote:
> >
> >Of a related note, the READONLY dos attribute can not be implemented
> >on SAMBA to work the same way as on NT.
> >
> >You can allow a client to set a file READONLY, but not to clear it.
> >Why?
> >
> >Because you do not know if the user intended to grant write access to
> >only themselves or the group and world.
> >
> I'm not sure that this is quite true. To a windows user, whether or not 
> a file is read only is entirely seperate from ACL permissions. A user 
> setting a file read only will expect it to be read only regardless of 
> any write access provided by ACL's. Conversely, clearing the read only 
> bit should allow write access as specified by the acl's or normal 
> permissions. This is essentually the same functionality as provided by 
> ext2's immutable flag. Under pc clients, the read only bit really isn't 
> a security feature tho, it's more of an advisory warning.

It is only an advisory warning that must be acknowledged for interactive
attempts to modify a file.

For non-interactive attempts it is manditory and blocks modification or
deletion of the file.  Scripts must specifically remove the readonly
attribute before replacing a file.  Even for the Administrator access.

Because the read-only attribute overrides an ACL that otherwise grants
modify access, it can not be correctly emulated on a UNIX or OpenVMS
filesystem with out changing the security policy of the host.  And that
is only possible on those operating systems that support ACLs.

Some compromise must be made.

Now on OpenVMS I could create an Identifier named SAMBA__DOS_ATTRIBUTE,
and grant it to all users.  Then when a SAMBA client specified the
Readonly bit, I could put an Access Control Entry on a file that had
higher priority than any other entry in the Access Control list.

That however has several disadvantages.  It requires that all accounts
have that identifier. (NT group membership).  It introduces a change to
the security model on the host operating system.  As it introduces a
change to the security model, it must be an optional feature, and disabled
by default.

 
> We use read only as an informal document control mechanisim. When a 
> document is released, it's marked as read only. That doesn't stop people 
> clearing the read only bit, but everyone here knows what it means. It 
> also means that if a released document does need to be edited, the users 
> can clear the readonly, but they will only have write access if the 
> permissions allow it.

They also need permissions to clear the readonly bit of course.
 
> The problem really boils down to under samba, we try and emulate a 
> non-security feature from the security of the file, which is never going 
> to be perfect. (I'm not critisising, I know why the current scheme was 
> chosen) For our environment, having the read only bit map to say the t 
> bit would be more usefull. The clients are all windows, so I don't have 
> to worry about unix access to the files, and because read only is then 
> seperate from the permissions, windows clients would get the expected 
> behaviour. Possibly a config option to change how the readonly bit is 
> presented would be a good idea.
> 
>  I may have just motivated myself into a patch :-)

Because of a fundemental difference in the OpenVMS security model and
UNIX, I could not use the current SAMBA scheme.  That is why I had
to do some research on the alternatives.

The big danger is implementing a system that gives a false sense of
security to the users.  Especially as a default.

Because the READONLY bit on NT has higher priority than any ACL on the
file, it is very easy to introduce a security hole in it's emulation,
especially on a platform that does not support ACLs.

Just because from an interactive GUI session, it allows being overriden
does not make it a non-security feature.  Unfortunately it has priority
over all other access.  On NT, I think that only a BACKUP program can
overwrite a READONLY file without manual user intervention.



Here are your configuration options as I see them, since almost anyone 
on this list knows the Unix security model better than I do, it may not
be inclusive.

dos_readonly = samba_only

   The readonly flag is used only for SAMBA clients and does not provide
   any protection other methods of accessing the file.

   Warning: This is not how it works on an NT server.  READONLY overrides
   the ACLs.  Users may not realize the file is not protected.

dos_readonly = owner

   Will report file as readonly if current user does not have write access
   to the file.  The user setting READONLY clears all write access via
   the mode bits.  The user clearing READONLY only enables write access to
   the owner field.

   Warning: If your operating system supports ACLs, either new Samba code
   must be written to remove read access to the file for all identifiers
   on the list when Readonly is SET, or else warn the user that the
   READONLY bit is not protecting the file as well as on NT.

   Users may not realize the file is not protected.

dos_readonly = group

   Same as with owner, but clearing the readonly bit allows group write
   access instead of user.

   Same warnings as above.

   This could be a common setting for shared access.

dos_readonly = world

   Same as with group and owner, but clearing the readonly bit allows the
   world write access.

   This is unsafe unless the host operating system supports ACLs to
   restrict things.

dos_readonly = report

   Reports the read-only status as that user sees it. User is not allow
   to change it directly and must change it through the group membership
   listing.

   This is the easiest to implement, and always shows the true state.

dos_readonly = ace

   The readonly attribute is implemented as an identifier, and it is
   up to the system admin to make sure that it functions as intended.

dos_readonly = nosupport

   The readonly bit will never be set.

Now are you going to have this parameter be global or per share?

And then there is the matter of that pesky System Attribute bit, and I
forgot about the Hidden attribute bit.


The only two options that I can find that a typical OpenVMS site would
be confortable with are the "=report" or "=nosupport".  They may also
buy in to "=ace" and "=samba_only" as options.

For me though, implementing "=ace" and "=samba_only" are the same.  And
the API to manipulate that is not the most friendly one to program to.
At this time just getting up to speed with the rest of the SAMBA community
has a higher priority.


-John
wb8tyw at qsl.network
Personal Opinion Only