Ola Lundqvist wrote:
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.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.
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
[EMAIL PROTECTED]
Personal Opinion Only
