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
