I have non-root user on windows 10 that can delete read-only backup files and folders on NFS.
Sent from ProtonMail Mobile On Tue, Jun 13, 2017 at 2:45 PM, Kenneth Gober <kgo...@gmail.com> wrote: 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 This may be what you are used to seeing on other systems, but this is not how Unix works. It may help you understand the situation if you consider that in Unix, a directory is nothing more than a list of names associated with inode numbers. Creating a file is actually a two-step process under the hood: first a new inode is allocated for the file, then a name is added to some directory, linking to the new inode. You can then add as many additional links to that same file as you like, in that same directory or in other directories. A file can therefore have many names and be found in many folders within the same file system. Permissions to read or write the file content (the inode) are based on the file permissions, and because the file permissions are for the inode (not the name) those permissions always apply no matter which name you use (you cannot have one name that allows writing, and another name that's read-only). If you want to remove one of the (possibly many) names for a file, you need write permission on the directory containing that name, because what you are doing is removing a link that connects that name to the inode. It does not matter whether you have permissions to read or write the content of the file because you are not touching the file -- other links to that same file remain undisturbed unless you remove those as well (assuming you have the directory permissions required). When the last link to a file is removed, the inode is deallocated and the file's data blocks are freed. The rules in Unix are then: 1. if you want to allow users to create or delete file names in a directory, give them write permission to the directory. 2. if you want to allow users to modify file contents, give them write permissions to the file. These rules are very simple, but they may not be the rules you are used to, and they are likely not the rules you want. But if you want different rules then you must choose a different system. If you want to use this system you need to apply these rules. -ken P.S. 4294967294 is the NFS 'nobody' uid -2 (expressed as an unsigned number), which is similar to but not the same as the 'nobody' uid -1. If the files you create end up owned by that uid, it means your client (Windows 10) is asserting that your uid is 0 (root). It is an NFS convention that being root on the client should not mean that you get root access to files on the server, so a client claiming to be root gets no permissions by default rather than all permissions. The 'map' and 'mapall' options override this behavior. @protonmail.com>
