NFSRODS

Presenting iRODS as NFSv4.1

November 18-21, 2019

Supercomputing 2019

Denver, CO

Kory Draughn

korydraughn@renci.org

Software Developer, iRODS Consortium

NFSRODS

Presenting iRODS as NFSv4.1

NFSRODS - Overview

• What
  • A new iRODS client
  • Presents iRODS as NFSv4.1
  • Allows an iRODS collection to be mountable
  • https://github.com/irods/irods_client_nfsrods

 

• Why
  • Provides a standard POSIX filesystem presentation to existing/legacy tools and applications
  • Provides full iRODS policy layer and enforcement

 

• How
  • A full nfs4j Virtual File System implementation
  • Implemented using Jargon
  • Deployed as a Docker container

NFSRODS v0.9 Release

Available today ...

 

Provides:

• Authentication: Trusted OS User
• Authorization: NFSv4.1 Access Control Lists

NFSRODS - Initial Authentication Model

Initially built with a hard requirement on Kerberos.  Why?

• We needed to distinguish users from each other.
• Kerberos provided access to the user's name which is what iRODS needed.
• NFS4J had built in support for Kerberos.

 

The Good:

• It worked!
• It had built-in authentication.

 

The Bad:

• It was too complex to stand up quickly.
• It required users and administrators to learn and manage Kerberos and all of it's tools which is not easy.
• It couldn't be containerized because Kerberos/Docker issues.

NFSRODS v0.9 - Current Authentication Model

• Assumptions
  • Authenticated access is via unix user with identically named iRODS user account.
  • Authenticated unix user is traversing the mount point (VM).
  • Entries in /etc/passwd and /etc/shadow are synced (uids/gids must match) on both the machine with the mount point (VM) and the machine running NFSRODS.

 

• Note
  • An authenticated user with sudo/root access on VM could appear to iRODS (and, therefore, all policy) as any user.

NFSRODS v0.9 - Authorization Model

• Maps iRODS permissions to/from NFSv4.1 ACLs.
• Traditional UNIX permissions are only set for the owner.
• Permissions managed via nfs4_getfacl and nfs4_setfacl.
• Collections are always executable, while data objects are never executable.

NFSRODS - Deployment

ubuntu$ git clone https://github.com/irods/irods_client_nfsrods

ubuntu$ cd irods_client_nfsrods

ubuntu$ docker build -t irods/nfsrods .

2. Build the image (if necessary):

• iRODS 4.2.6
• Update Collection MTime Rule Engine Plugin
• Docker

1. Requirements:

NFSRODS - Deployment (cont.)

ubuntu$ cat /home/ubuntu/nfsrods_config/server.json
{
    "nfs_server": {
        "port": 2049,
        "irods_mount_point": "/tempZone",
        "user_information_refresh_time_in_milliseconds": 3600000,
        "file_information_refresh_time_in_milliseconds": 1000,
        "user_access_refresh_time_in_milliseconds": 1000
    },

    "irods_client": {
        "zone": "tempZone",
        "host": "irods-server.sc19",
        "port": 1247,
        "default_resource": "demoResc",
        "ssl_negotiation_policy": "CS_NEG_REFUSE",
        "proxy_admin_account": {
            "username": "rods",
            "password": "rods"
        }
    }
}

3. NFSRODS Configuration:

NFSRODS - Deployment (cont.)

ubuntu$ docker run -d --name nfsrods \
        -p 3000:2049 \
        -v /home/ubuntu/nfsrods_config:/nfsrods_config:ro \
        -v /etc/passwd:/etc/passwd:ro \
        -v /etc/shadow:/etc/shadow:ro \
        irods/nfsrods:latest

ubuntu$ sudo mkdir -p /mnt/the_nfsrods_mountpoint
ubuntu$ sudo mount -o sec=sys,port=3000 `hostname`:/ /mnt/the_nfsrods_mountpoint

5. Create the mount point:

4. Launch the NFSRODS Docker container:

bobby$ cd /mnt/the_nfsrods_mountpoint/home/bobby
bobby$ echo "science" > science.txt
bobby$ ls -l science.txt
-rw------- 1 bobby bobby 8 May 15 17:29 science.txt
bobby$ cat science.txt
science

6. Use the mount point:

NFSRODS v0.9

Demo

NFSRODS - Science. Done.

GREAT!!!

 

Let's run all of our tools against NFSRODS, right?

NFSRODS - Science. Done.

Well ...

NFSRODS v0.9 - Caveats

• Speed
  • NFSRODS will be slower than using direct clients (e.g. icommands)

 

• Caching
  • NFS caches file and directory information between all requests
  • Possible information leakage
  • Possible out-of-date information
  • Increasing consistency decreases speed

 

Consider passing lookupcache=none as an additional option to mount. Although NFSRODS will be less responsive, the benefit to using this is that information will be more consistent and less likely to be leaked to users with more restrictive access.

NFSRODS - Future Work

• SSL/TLS
• Parallel Transfer
• Unit Testing
• NFStest - POSIX Filesystem Level Access Testing

 

• SMBRODS - Possible sister project to make iRODS accessible to Microsoft Windows machines

Questions?

• Thank you!

 

• This version (NFSv4.1) of NFSRODS was built by:
  • Kory Draughn, iRODS Consortium
  • Alek Mieczkowski, iRODS Consortium
  • Mike Conway, NIH/NIEHS
  • Jason Coposky, iRODS Consortium
  • Terrell Russell, iRODS Consortium

 

• Inspired by work (NFSv3) presented at UGM2016 (slides, paper):
  • Danilo Oliveira, Center for Informatics UFPE, Brazil
  • I. Fé, Center for Informatics UFPE, Brazil
  • A. Lobo Jr., Center for Informatics UFPE, Brazil
  • F. Silva, Center for Informatics UFPE, Brazil
  • G. Callou, Center for Informatics UFPE, Brazil
  • V. Alves, Center for Informatics UFPE, Brazil
  • P. Maciel, Center for Informatics UFPE, Brazil
  • Stephen Worth, EMC Corporation

 

• Preliminary testing provided by:
  • Bristol-Myers Squibb Company
  • University of Colorado Boulder Research Computing