Worse, though, is if you think that a security issue on a file server is because of a problem in the default client configuration.
Mind you, this is not completely general (load issues and integrity issues do matter on the client side), but when we're talking about granting of permissions on those files it's about as wrong as you can get. -- Raul On Tue, Jun 13, 2017 at 1:47 AM, Otto Moerbeek <o...@drijf.net> wrote: > On Tue, Jun 13, 2017 at 01:24:19AM -0400, Rupert Gallagher wrote: > >> If a non-root user can delete a root owned file with read-only permissions, >> then there is a security problem. Good luck to you if you are thinking >> otherwise. > > This is not how unix permissions work. The directory permissions > detemine if you can remove a file. > > If you expect otherwise, you should adapt your expectations. > > -Otto > >> >> The windows nfs umask solves the problem of writing files to both user and >> group. It certainly does not solve the above security problem. >> >> Sent from ProtonMail Mobile >> >> On Mon, Jun 12, 2017 at 10:27 PM, Raul Miller <rauldmil...@gmail.com> wrote: >> You have a very odd idea of "security". Probably though, this is the >> wrong mailing list for what you are trying to do. >> >> Good luck, >> >> -- >> Raul >> >> On Mon, Jun 12, 2017 at 2:27 PM, Rupert Gallagher <r...@protonmail.com> >> wrote: >> > I think the problem is how windows mounts the nfs folder by default (right >> > click on "this computer" then select to attach a network folder to a drive >> > letter). The following article by Microsoft describes the mount option >> > "fileaccess" to set a default umask: >> > >> > https://technet.microsoft.com/en-us/library/cc754350(v=ws.11).aspx >> > >> > This option is not available from the default menu. >> > >> > Sent from ProtonMail Mobile >> > >> > On Mon, Jun 12, 2017 at 7:24 PM, Raul Miller <rauldmil...@gmail.com> >> > wrote: p.s. if you do not want windows files in that shared directory to be >> > executable, I think you can mount the nfs backing store partition >> > noexec. >> > >> > I haven't tested this, though - I mostly try to avoid networked file >> > systems. >> > >> > Thanks, >> > >> > -- >> > Raul >> > >> > On Mon, Jun 12, 2017 at 1:22 PM, Raul Miller <rauldmil...@gmail.com> wrote: >> >> Ok, look... >> >> >> >> Your problem 1: all windows files are executable because the windows >> >> model for executable or not is proprietary and not supportable. It's >> >> also not clear why you should care about this in a shared directory. >> >> >> >> Your problem 2: if we assume that a shared directory (rather than user >> >> specific directories) is the right approach, and if we also assume >> >> that each user's claim to a file name should deny write access to >> >> other users with that file name, we need to look at the permissions on >> >> the containing directory. >> >> >> >> In your case, you have drwxrwxr-x -- this means that everyone who is a >> >> member of the staff directory has the right to remove directory >> >> entries. If you do not want that, you need to change the permissions >> >> on the directory: http://man.openbsd.org/sticky.8 >> >> >> >> But, note that if you are changing the owner on the files to not match >> >> that of the user who created the files, you should expect that people >> >> will not be able to delete files that they themselves created. >> >> >> >> Your problem 3: this is a consequence of your having changed the owner >> >> of the file. Your file permissions say that only the owner can change >> >> the file. >> >> >> >> With this in mind, I think I can see how I would change things to >> >> match what you seem to be claiming that you want: >> >> >> >> (1) remove the user id mapping >> >> >> >> (2) set the sticky bit on the Shared directory. >> >> >> >> If you do not want this, I think you need to spend a little time >> >> thinking about what it is that you actually want, and whether or not >> >> that should even be possible. >> >> >> >> (So far, you have only mentioned an example uid value for a user as >> >> perhaps being an issue. This, combined with the subject line in this >> >> thread are the only clues I have as to why you might not have removed >> >> the user id mapping. But why this should even be an issue for you is >> >> unclear to me.) >> >> >> >> Thanks, >> >> >> >> -- >> >> Raul >> >> >> >> >> >> On Mon, Jun 12, 2017 at 12:58 PM, Rupert Gallagher <r...@protonmail.com> >> >> wrote: >> >>> On problem 2, >> >>> >> >>> if a user has group write permission on a folder, it has permission to >> >>> write its own files and those of same group membership in that folder, >> >>> provided the group permission is set on the file by its owner. If a file >> >>> belongs to me and I deny write permission to group and other, then >> >>> nobody can write my file. File creation and destruction are forms of >> >>> writing. This is what I am used to see. The ability of a windows nfs >> >>> user to delete a file for which it has no write permission is a security >
