I have the backup on NAS. Files and folders read only. Users can delete anything.
Sent from ProtonMail Mobile On Tue, Jun 13, 2017 at 7: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 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 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 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 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 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 @protonmail.com> @gmail.com> @gmail.com> @protonmail.com> @gmail.com>
