improved dos attribute handling
John E. Malmberg
wb8tyw at qsl.net
Fri Jan 31 16:28:14 GMT 2003
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
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
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
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.
wb8tyw at qsl.network
Personal Opinion Only
More information about the samba-technical