RFC 8275

RFC 8275 💖 Allowing Inheritable NFSv4 Access Control Entries to Override the Umask

okay bestie, this one is from December 2017 🎀 It's by J. Fields and A. Gruenbacher, both at Red Hat 💅 It's on the Standards Track, so it's a real IETF standard, iconic 👑 It's published under ISSN 2070-1721. Section 3 says it extends NFSv4.2 but does not update RFC 7862 or RFC 7863, so those stay as they are 🫶

Abstract

okay so the main drama: inheritable NFSv4 Access Control Entries (ACEs) can get totally ignored because of the per-process file mode creation mask (umask) 😭 The fix is to send the umask and the create mode as two separate pieces of data. That way the server can make smarter choices about which permissions to set on new files 🧠 This document proposes a protocol extension to make it happen ✨

Status of This Memo

This is an Internet Standards Track document 👑

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 📚

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8275 🦋

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they explain your rights and restrictions for this document 📜 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💜

Table of Contents

1.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
3.  Protocol Extension Considerations . . . . . . . . . . . . . .   3
4.  XDR Extraction  . . . . . . . . . . . . . . . . . . . . . . .   3
5.  The mode_umask Attribute  . . . . . . . . . . . . . . . . . .   4
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
  8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1. Problem Statement 🌸

okay so on Unix-like systems, every process has a file mode creation mask (umask) 🧚 The umask says which permissions have to be turned off when new file system objects get created.

Now here's the tea ☕ When it comes to applying the mode, Section 6.4.1.1 of [RFC7530] says servers SHOULD keep the permissions granted to any user or group named in the Access Control List (ACL) to be no more than what the MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP bits give. Servers that want to act like Unix-style chmod may also be motivated by the same stuff in [SUSv4]. (Check the discussion of extra and alternate access control mechanisms in "File Permissions", Section 4.4 of [SUSv4] if you want the full picture 👀)

Here's the problem bestie 😭 On lots of existing installs, every ordinary user has the same effective group ID by default. To stop everyone from getting full access to each other's files, those installs usually set a umask that's super restrictive. The result? Inherited ACL entries (inheritable ACEs), which describe permissions for named users and groups, often get ignored. So inheritable ACEs are useless in a bunch of common situations 💀

Linux fixes this for local file systems by ignoring the umask whenever a new file inherits ACEs from its parent. See [LinuxACL] 💅

The same fix should work for NFS, right? Well, not quite 🙈 The NFSv4 protocol doesn't currently let the client send over the umask of the process that's opening a file. Clients also have no way to check for inheritable permissions and only apply the umask when it's actually needed, all in one atomic step. So the server gets an OPEN with a mode attribute that already has the umask applied. Not iconic 😤

This document fixes it by defining a new attribute. It lets the client send the umask and the mode given at file creation separately, so the client can ignore the umask when inheritable ACEs are around. At least in the Linux case, this means NFSv4 can provide the same semantics you get with local access 🦋

2. Conventions Used in This Document ✨

Here's the BCP 14 part, the important vocab for reading the spec 📚 The key words are:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Protocol Extension Considerations 🧚

This document is an extension to minor version 2 of the NFSv4 protocol, as described in [RFC8178] 💖 It describes a new OPTIONAL feature. NFSv4.2 servers and clients that were built without knowing about this extension will keep interoperating with clients and servers that do know about it, whether or not those support it. Mutual respect 🫶

Also, [RFC7862] doesn't define NFSv4.2 as non-extensible, so [RFC8178] treats it as an extensible minor version. This Standards Track RFC extends NFSv4.2 but does not update [RFC7862] or [RFC7863] 👑

4. XDR Extraction 🎀

The extra lines of External Data Representation (XDR) [RFC4506] description embedded in this document can be pulled out by feeding this document into the shell script below 🔥

<CODE BEGINS>

#!/bin/sh
grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'

<CODE ENDS>

So if the script above is saved as a file called "extract.sh", and this document is saved as a file called "umask.txt", the reader can run:

sh extract.sh < umask.txt > umask.x

What the script actually does is strip leading white space from each line, plus a sentinel sequence of "///" ✨

Once that extraction is done, these added lines need to go into an appropriate base XDR. That base is the generated XDR from [RFC7863], together with XDR from any extra extensions the implementation recognizes. Put it all together and you get a ready-to-compile XDR file 💜

Acknowledgments 🙏✨

Okay bestie, the thank-you section! 🫶 Trond Myklebust and Dave Noveck reviewed this and suggested defining it as a (mode, umask) pair instead of just umask, which is such a good call 👑. Warren Kumari, Adam Roach, Spencer Dawkins, Mike Kupfer, and Thomas Haynes all reviewed it too, and Thomas Haynes also helped with XDR 💖.

Authors' Addresses 🎀

The two people who wrote this are J. Bruce Fields and Andreas Gruenbacher, both at Red Hat, Inc. 💅

J. Bruce Fields Red Hat, Inc.

Email: bfields@redhat.com

Andreas Gruenbacher Red Hat, Inc.

Email: agruenba@redhat.com