Re: improved dos attribute handling
Hi On Sat, Feb 15, 2003 at 09:19:46PM -0500, John E. Malmberg wrote: Ola Lundqvist wrote: 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. :) Bcc: by request. Thanks. I have now subscribed but I think it failed so please Cc: me until I got my subscription right. snipped 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. There is such a thing as file owners in a domain file server. This will show up in the file properties on Windows under the security properties. As long as your patch is a selectable behavior, there are probably a lot of systems that could use it. Right now it is selectable but not as a new option. In fact it is activated by the 'dos filemode' option. If someone can give me a pointer to or a good advice on how to add such an option. I just wanted to make clear that it does have side effects when you are not running in an appliance mode, or if your users are in multiple UNIX groups. That is true. I do not run UNIX, I run OpenVMS. It uses a UIC based protection model that is similar to UNIX but there might be some differences that are important that I may be overlooking. I can give users write access to a file with out giving them write access to the entire directory. Write access to the directory implies that they can add and remove files. So adding the world write permission back to a file that the user owns when the READONLY bit is cleared will allow every other user on the system write access to that file, if they know it's path. On the other hand you can still do that because the user can copy the file, delete the old one, create a new one and copy in the content. Does UNIX require you to have write access to a directory to modify a file that you have write access to? No. 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. As I pointed out above, at least on OpenVMS, that is not a valid assumption as to what the users wishes are for the world and group access. Just because they have permission to set them does not mean that they mean to. I do not know openvms good enough so I can not tell. :) Regards, // Ola -John [EMAIL PROTECTED] Personal Opinion Only -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 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 / ---
Re: improved dos attribute handling
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
User with read only access can deny write.
Hello (I'm not subscribed to this list so please Cc: me). I have reported an issue to the Debian bug tracking system but the maintainer thought that it was better to ask upstream. So now I do that. This is the first of three issues. The description is found in: http://bugs.debian.org/178784 The relevant part from the initial mail sent there is pated here: I have got a small problem. The thing is that if one use A open a file in microsoft word without having write access to the file the file become locked. From smbstatus: 19717 DENY_WRITE RDONLY NONE /home/pathtofile The problem is that all other users can not write to the file because it is locked. This is a problem here because some users need to be able to write the file while other just have read access. You could say that it is a bug in word but on the other hand it should really be possible to deny write whily you do not have write permission. I assume that this is a bug, i.e. no check is performed to determine if a user really can deny write to other users. Or is this a design flaw in samba? If you can give me an indication on where to look in the code I'll try to make a patch for you. Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 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 / ---
improved dos attribute handling
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. For other information, see: http://bugs.debian.org/178801 The patch is located at (against the debian version of 2.2.3a): http://cvs.opal.dhs.org/viewcvs.cgi/samba-fixes/dchmod/samba-dchmod.patch?rev=1.1content-type=text/vnd.viewcvs-markup or just http://cvs.opal.dhs.org/viewcvs.cgi/samba-fixes/dchmod/ if you want to look at the files directly. The patch includes the changes to the smbd makefile and dosmode.c file. I had to write some functions myself because the normal C-functions did not really behave as windows functions... That did not surprise me a lot though. :) Best regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 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 / ---
Move files do not change group as copying does.
Hello (I'm not subscribed to please Cc: me). I have a problem with movement of files: The problem this time is that we have set up a permission structure for files in about the same way as windows do, using groups. The problem is that in windows, the files inherit the group membership from the directory where the files (and subdirs) reside. This works fine now if the user copy the files from one place to the other. The problem is that if the files (and dirs) is moved an ordinary rename(a,b) command is used which means that the group membership is not changed. I use sgid on directorys to emulate windows behaviour but this do not help if moving files. I have looked at the code and see that there is a rename(a,b) emulation function, but that tries to emulate it truely so it gives the same problem. My suggestion is that a recursive chgrp is performed to the destination for all dirs and files that has the same group id as the source file or dir. What do you think about this? The inherit acls = yes option do not seem to help here because, first you need acl kernel support and second the same code for moving files is used (but I can be mistaken). I need to get some feedback where to patch the code and if you are interested in it. You can also see the debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=178800 From IRC (if that can be interesting): debian-opal Is there anyone in here who can explain how the vfs_rename function is supposed to work? Exactly what arguments can you expect that it gets? debian-opal I'm trying to create a emulation of windows group membership inheritance. debian-opal It works ok if copying files but not if moving. *SNIP* abartlet debian-opal: I would be worried about the races with that proposal debian-opal abartlet: Yes that can be a problem. The problem is that our customer needs to emulate that... idra debian-opal: emulate what exactly? abartlet you want to emulate racy windows code? abartlet (I understand much of the ACL stuff races on WinNT too...) debian-opal The problem is that we have set up a permission structure on a customer server. The permissions are based on the directory where things are located. idra inheritance is just yet another demonstration of how good basis are converted in braindamaged implementations at MS ... :-( debian-opal If you copy files the group get inherited because the sgid bit is set on the dir. The problem is with moving files. idra debian-opal: so if you move files they retain the ownership ... idra instead of inheriting the one set in the directory, right? debian-opal Yes. idra uhmmm idra I think this is a bug for jeremy idra have you written on [EMAIL PROTECTED] ? debian-opal Nope. I wanted to ask here if someone knew, so I could patch it nice and quickly. idra then write asap on the list, maube cc to jeremy directly *SNIP* idra debian-opal: you are using the proper smb.conf options for inheritance on that share? debian-opal I think so. Are there any options that cause the rename thing not to be used? debian-opal Do the dos inherit = yes really fix this? debian-opal Sorry. inherit acls = yes. Don't I need acl support in the kernel? idra yes you need ACL idra but any kind of proper inheritance need ACLs idra (Imho) debian-opal Ok. The manual page is talking about creating a file/dir... not about moving. Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 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 / ---
