improved dos attribute handling

[Ola Lundqvist]

Sorry. I'm not subscribed to this list so I could not
preserve the reply-to header. Please Cc: me if you
want me to know the mail. :)

John E. Malmberg wrote:
>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.

Yes, I'm aware of that. My solution is based on that all users
can only access the data using samba, and do not have a shell account.
I have not analyzed problems with shell accounts (yet).

>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.

You are probably right. On the other hand, samba could deny every write
to a file that has no write permission, even if the user is administrator.
It would need more patching though.

>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.

On the other hand, with the current setup users must have administrative
rights to modify read-only bit. This is a problem because in a windows
environment (with users used to windows stuff) there is no such thing as
file owners.

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

And that is why I check the directory permissions. Iff the user has
write access to the directory and is member of the file it can
modify the permissions.

>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.

I assume that in this situation the user has no write access to
the directory and thus will be denied access.

If you have write access to the directory you can actually (with
normal posix permissions) go around this anyway. Just copy the
file, delete the old and move it back to its original place.

Test using:
touch foo
sudo chown otheruser foo
sudo chmod g-w foo
rm foo
> rm: Remove write protected file "foo"? y
ls -l foo
> ls: foo: File or directory not found

So "my" patch do not change anything. I just make the copy, del, move
thing easier (using the usual dialog box).

>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.

True.

>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.

I have not tried to emulate the admin accounts on windows.

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

Yes. :)

>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.

Yes, you are probably right. As I have told before, I have not tried
to emulate windows admin accounts, just usual users.

Your comments are good, but I still think my patch solves the usual
user problem. Not admin accounts though (they are a problem now too).

>-John
>wb8tyw at qsl.network
>Personal Opinion Only

Regards,

// Ola

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal at debian.org                     Annebergsslingan 37      \
|  opal at lysator.liu.se                 654 65 KARLSTAD          |
|  +46 (0)54-10 14 30                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------