linux-kernel - Re: Should we split the network filesystem setup into two phases?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH2r5mvLSf2Cqdi9LwVre2MyiSh+7ZxGgRp_Am3D_090oFDCzw@mail.gmail.com>
Date:   Thu, 16 Aug 2018 13:36:13 -0500
From:   Steve French <smfrench@...il.com>
To:     Aurélien Aptel <aaptel@...e.com>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        David Howells <dhowells@...hat.com>,
        trond.myklebust@...merspace.com,
        Anna Schumaker <anna.schumaker@...app.com>,
        Steve French <sfrench@...ba.org>,
        Steve Dickson <steved@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        ebiederm@...hat.com, linux-api@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, linux-nfs@...r.kernel.org,
        CIFS <linux-cifs@...r.kernel.org>, linux-afs@...ts.infradead.org,
        ceph-devel@...r.kernel.org, v9fs-developer@...ts.sourceforge.net
Subject: Re: Should we split the network filesystem setup into two phases?

On Thu, Aug 16, 2018 at 12:23 PM Aurélien Aptel <aaptel@...e.com> wrote:
>
> Steve French <smfrench@...il.com> writes:
> > In cifs we attempt to match new mounts to existing tree connections
> > (instances of connections to a \\server\share) from other mount(s)
> > based first on whether security settings match (e.g. are both
> > Kerberos) and then on whether encryption is on/off and whether this is
> > a snapshot mount (smb3 previous versions feature).  If neither is
> > mounted with a snaphsot and the encryption settings match then
> > we will use the same tree id to talk with the server as the other
> > mounts use.  Interesting idea to allow mount to force a new
> > tree id.
>
> We actually already have this mount option in cifs.ko, it's "nosharesock".

Yes - good point.  It is very easy to do on cifs.  I mainly use that to simulate
multiple clients for testing servers (so each mount to the same server
whether or not the share matched, looks like a different client, coming
from a different socket and thus with different session ids and tree
ids as well).

It is very useful when trying to simulate multiple clients running to the same
server while using only one client machine (or VM).

> > What was the NFS mount option you were talking about?
> > Looking at the nfs man page the only one that looked similar
> > was "nosharecache"

The nfs man page apparently discourages its use:

"As of kernel 2.6.18, the behavior specified by nosharecache is legacy
caching behavior. This is  considered  a  data risk"


-- 
Thanks,

Steve