(also, once again, sticky bit) -- Raul
On Tuesday, June 13, 2017, Raul Miller <rauldmil...@gmail.com> wrote: > 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 > <javascript:;>> 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 > <javascript:;>> 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 > <javascript:;>> 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 > <javascript:;>> 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 > <javascript:;>> 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 <javascript:;>> 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 > > >
