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
