improved dos attribute handling

[John E. Malmberg]

Ola Lundqvist wrote:
> Hello again.
> 
> This is the next issue for which I have created a patch.
> 
> There is a problem with the current dos filemode option. The
> problem is that you can only set read only but not remove it
> again. You can of course not because you do no longer have
> write permissions to the file. My fix change the behaviour to
> check the directory and file for permissions.
> 
> If the user has write permission to the dir and
> (is owner of file, or member of group or part of group) of
> the file the read-only can be removed. The code is tested
> but not for very long time. Right now just a week in a
> production server. I have not checked if it is possible to
> bypass something but I do not think so. I think I have catched
> all cases, but checking is good.

You are aware that this can introduce a security hole because the way 
that DOS / Windows handles the Readonly bit is quite different than in a 
POSIX or UNIX environment.

In the Microsoft Windows and DOS environment, the Readonly attribute 
means that no one has write or delete access to the file, not even the 
Administrator or "root" account.

If your platform supports ACLs, the Readonly bit is supposed to overide 
them also.

So unless you change the security model of the host platform, it is not 
possible to have the Readonly attribute behave the way that it does in a 
Microsoft Windows environment.

Now you can determine if the file is "Readonly" to the client, and use 
the bit to report this.  But it is not possible to for a POSIX host to 
allow the client to change this attribute and have it have the same effect.

The model of simulating a "Readonly" bit by removing Write and delete 
access from the Owner, Group, and World bits is ignoring that "root" or 
"setuid root" programs can still write to the file, and does not take 
into account that ACLs can still grant write access.

The problem with this, is that while you can allow the client to remove 
the write/delete bits from a file that they have permission to change 
the permission on, it is not good to have the client put the write 
permissions back on.

You simply do not know what the Group and World settings were prior to 
the Readonly attribute being set.

If you have a file that starts out: W:readonly, G:readonly, 
O:read-write, and the client sets the "Readonly" bit, then the result is 
obvious.  When the client clears Readonly bit, then if you just add 
"Write and Delete" access to the owner, everthing is back to normal.

However if the file starts out: W:readonly, G:read-write, and 
O:read-write, and when the client sets the "Readonly" bit, write access 
is removed from the Group, and Owner.  But what happens when you just 
set the O: write+delete settings when the client clears the "Readonly" 
bit, the other members of the group still will not have write access to 
the file.

A similar situation will exist in the event that the file started out 
with W:write+delete access.

Now with ACLs implemented on the host platform, even this simulation 
will not work.  The "Readonly" bit based on solely on the protection 
mask becomes totally misleading.  You can set it or clear it, but it may 
have no effect on access to the file by either the host programs or to 
clients.

With ACLs, you can create a SAMBA_READONLY entry, and then use that to 
simulate the READONLY bit.  But it must be applied in such a way that 
gives it priority over all ACEs.  Because it is a "DENY" if present ACE, 
on OpenVMS, it would require that all user accounts have that identifier 
granted to them.

But because "root" privilege still overides the ACL, it is still not the 
same as on an Microsoft server.

If you are not concerned about having the "Readonly" attribute apply to 
access from the host system, it becomes much easier to implement.

But it is almost impossible to implement correctly, and all close 
simulations have drawbacks.

So any hack to improve "Readonly" for a particular group of users, may 
not be correct for another group of users, and must be customizable.

And as a preemption for the comment that a Microsoft Windows 
Administrative account can overide the "Readonly" attribute.  It can 
not.  What it can do is turn the attribute off, but it can not write or 
delete the file until that attribute is removed.

-John
wb8tyw at qsl.network
Personal Opinion Only