Message-ID: <5cd3f0c0-38b0-6929-5e27-c709c57a4d0f@auristor.com>
Date:   Wed, 19 Feb 2020 20:56:39 -0500
From:   Jeffrey E Altman <jaltman@...istor.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        David Howells <dhowells@...hat.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>, linux-afs@...ts.infradead.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] afs: Create a mountpoint through symlink() and remove
 through rmdir()

Hi Linus,

response inline ...

On 2/19/2020 8:21 PM, Linus Torvalds wrote:
> On Wed, Feb 19, 2020 at 4:11 PM David Howells <dhowells@...hat.com> wrote:
>>
>> If symlink() is given a magic prefix in the target string, turn it into a
>> mountpoint instead.
>>
>> The prefix is "//_afs3_mount:".
> 
> That sounds sane.
> 
> Your argument that if the prefix is made really long it couldn't be a
> valid symlink at all on AFS is fair, but seems somewhat excessive.

My understanding is that the prefix is not something that will be stored
on the server. Isn't the prefix intended to provide a namespace so that
a symlink target passed to a smb3/cifs filesystem can filter out the
invalid server name?

AFS symlinks have a maximum target string length of 1024 octets
including the trailing NUL.  The maximum cell name is 255 which matches
the maximum DNS name length.  The maximum volume name length is 255
in AuriStorFS and 31 in AFS3.

> The only issue I see with this interface is that you can now create
> these kinds of things by untarring a tar-ball etc.

There is no security issue here.  AFS volumes do not need to be mounted
in the /afs file namespace in order to access the volume's root
directory.  A mount point such as implemented here is just a reference
to a volume root.

OpenAFS provides a generic interface

  /afs/.:mount/<cell-name>:<volume-name-or-id>/

to access any volume's root directory and

  /afs/.:mount/<cell-name>:<volume-name-or-id>:<vnode-id>:<unique-id>

to access any AFS3 object by its object identifier whether its a
directory, file, symlink, etc.

Linux can of course mount arbitrary volumes using mount. For example:

 mount -t afs "#auristor.com:user.jaltman." /home/jaltman

There are existing AFS tools such as afs-up which clones a directory
tree from one place to another.  On Windows the AFS3 mount points and
symlinks are exposed as reparse points and can be copied from place to
place using tools such as Microsoft's robocopy; including to NTFS.

AFS3 mount points are also stored in AFS dump files which are similar to
tar files.

> I can see that being both very convenient and a possible security
> pain. But I'm assuming that the real security is on the server side
> anyway and not just anybody can create arbitrary things like these?

The security of AFS3 is provided by the enforcement of Access Controls
as interpreted by the AFS3 fileservers.  For OpenAFS the ACLs are stored
only on directories.  AuriStorFS cells enforce Volume ACLs and Object
ACLs which include ACLs on directories, files, symlinks and mount points.

ACL interpretation is performed by evaluating the applicable ACLs
against the current protection set (user id and membership group ids)
attributed to the combined authentication identities bound to the RPC
request.

If curious,

 https://www.auristor.com/documentation/man/linux/7/auristorfs_acls.html

The computed rights granted to the caller are transmitted to the
requesting client as part of the status response.  This permits the
caller to cache the permissions along with the Callback promise.  The
permissions are discarded by the client when the Callback promise is
broken or expires.

Thanks for your assistance with refining the functional implementation.

Jeffrey Altman


View attachment "jaltman.vcf" of type "text/x-vcard" (272 bytes)

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4033 bytes)

Powered by blists - more mailing lists