On Tue, Jun 13, 2017 at 12:25 PM, Rupert Gallagher 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.
>
> I did not say that.
And yet:
On Mon, Jun 12, 2017 at 2:27 PM, Rupert Gallagher wrote:
> I think t
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 wrote: On
Mon, Jun 12, 2017 at 12:58 PM, Rupert Gallagher wrote: > On problem 2, > > if a
user has group write permission on
> Worse, though, is if you think that a security issue on a file server is
> because of a problem in the default client configuration.
I did not say that.
Sent from ProtonMail Mobile
On Tue, Jun 13, 2017 at 1:10 PM, Raul Miller wrote:
Worse, though, is if you think that a security issue on a
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 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-onl
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
(also, once again, sticky bit)
--
Raul
On Tuesday, June 13, 2017, Raul Miller 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
>
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
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
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.
The windows nfs umask solves the problem of writing files to both user and
group. It certainly does not solve the above security problem.
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 com
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/l
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
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
specifi
... a security problem.
Sent from ProtonMail Mobile
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
Errata:
> /etc/exports contains
> /exports/Shared -mapall=nobody:shared [client-ip]
Correction:
/exports/Shared -mapall=nobody:staff [client-ip]
create and delete here is based on directory permissions.
edit is presumably based on file permissions.
That said, generally speaking, windows permissions are incredibly
complex and (as a result) mostly ignored. [There will be a few people
who will deny this, but as a general rule most people den
Context:
A windows 10 pro client connects to openbsd nfs shared folder using username
and password on the openbsd system.
/etc/exports contains
/exports/Shared -mapall=nobody:shared [client-ip]
permissions:
drwxr-xr-x root wheel exports/
drwxrwxr-x nobody staff exports/Shared/
user is a member
18 matches
Mail list logo
