)]}'
{
  "commit": "426b4ca2d6a5ab51f6b6175d06e4f8ddea434cdf",
  "tree": "86d8d8e4ef6d072ad262a3be79fe680e164837f0",
  "parents": [
    "b8dcef877ab5f2637fccd3efb6fe169c8211961a",
    "5fadbd992996e9dda7ebcb62f5352866057bd619"
  ],
  "author": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Tue Aug 09 09:52:28 2022 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Tue Aug 09 09:52:28 2022 -0700"
  },
  "message": "Merge tag \u0027fs.setgid.v6.0\u0027 of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux\n\nPull setgid updates from Christian Brauner:\n \"This contains the work to move setgid stripping out of individual\n  filesystems and into the VFS itself.\n\n  Creating files that have both the S_IXGRP and S_ISGID bit raised in\n  directories that themselves have the S_ISGID bit set requires\n  additional privileges to avoid security issues.\n\n  When a filesystem creates a new inode it needs to take care that the\n  caller is either in the group of the newly created inode or they have\n  CAP_FSETID in their current user namespace and are privileged over the\n  parent directory of the new inode. If any of these two conditions is\n  true then the S_ISGID bit can be raised for an S_IXGRP file and if not\n  it needs to be stripped.\n\n  However, there are several key issues with the current implementation:\n\n   - S_ISGID stripping logic is entangled with umask stripping.\n\n     For example, if the umask removes the S_IXGRP bit from the file\n     about to be created then the S_ISGID bit will be kept.\n\n     The inode_init_owner() helper is responsible for S_ISGID stripping\n     and is called before posix_acl_create(). So we can end up with two\n     different orderings:\n\n     1. FS without POSIX ACL support\n\n        First strip umask then strip S_ISGID in inode_init_owner().\n\n        In other words, if a filesystem doesn\u0027t support or enable POSIX\n        ACLs then umask stripping is done directly in the vfs before\n        calling into the filesystem:\n\n     2. FS with POSIX ACL support\n\n        First strip S_ISGID in inode_init_owner() then strip umask in\n        posix_acl_create().\n\n        In other words, if the filesystem does support POSIX ACLs then\n        unmask stripping may be done in the filesystem itself when\n        calling posix_acl_create().\n\n     Note that technically filesystems are free to impose their own\n     ordering between posix_acl_create() and inode_init_owner() meaning\n     that there\u0027s additional ordering issues that influence S_ISGID\n     inheritance.\n\n     (Note that the commit message of commit 1639a49ccdce (\"fs: move\n     S_ISGID stripping into the vfs_*() helpers\") gets the ordering\n     between inode_init_owner() and posix_acl_create() the wrong way\n     around. I realized this too late.)\n\n   - Filesystems that don\u0027t rely on inode_init_owner() don\u0027t get S_ISGID\n     stripping logic.\n\n     While that may be intentional (e.g. network filesystems might just\n     defer setgid stripping to a server) it is often just a security\n     issue.\n\n     Note that mandating the use of inode_init_owner() was proposed as\n     an alternative solution but that wouldn\u0027t fix the ordering issues\n     and there are examples such as afs where the use of\n     inode_init_owner() isn\u0027t possible.\n\n     In any case, we should also try the cleaner and generalized\n     solution first before resorting to this approach.\n\n   - We still have S_ISGID inheritance bugs years after the initial\n     round of S_ISGID inheritance fixes:\n\n       e014f37db1a2 (\"xfs: use setattr_copy to set vfs inode attributes\")\n       01ea173e103e (\"xfs: fix up non-directory creation in SGID directories\")\n       fd84bfdddd16 (\"ceph: fix up non-directory creation in SGID directories\")\n\n  All of this led us to conclude that the current state is too messy.\n  While we won\u0027t be able to make it completely clean as\n  posix_acl_create() is still a filesystem specific call we can improve\n  the S_SIGD stripping situation quite a bit by hoisting it out of\n  inode_init_owner() and into the respective vfs creation operations.\n\n  The obvious advantage is that we don\u0027t need to rely on individual\n  filesystems getting S_ISGID stripping right and instead can\n  standardize the ordering between S_ISGID and umask stripping directly\n  in the VFS.\n\n  A few short implementation notes:\n\n   - The stripping logic needs to happen in vfs_*() helpers for the sake\n     of stacking filesystems such as overlayfs that rely on these\n     helpers taking care of S_ISGID stripping.\n\n   - Security hooks have never seen the mode as it is ultimately seen by\n     the filesystem because of the ordering issue we mentioned. Nothing\n     is changed for them. We simply continue to strip the umask before\n     passing the mode down to the security hooks.\n\n   - The following filesystems use inode_init_owner() and thus relied on\n     S_ISGID stripping: spufs, 9p, bfs, btrfs, ext2, ext4, f2fs,\n     hfsplus, hugetlbfs, jfs, minix, nilfs2, ntfs3, ocfs2, omfs,\n     overlayfs, ramfs, reiserfs, sysv, ubifs, udf, ufs, xfs, zonefs,\n     bpf, tmpfs.\n\n     We\u0027ve audited all callchains as best as we could. More details can\n     be found in the commit message to 1639a49ccdce (\"fs: move S_ISGID\n     stripping into the vfs_*() helpers\")\"\n\n* tag \u0027fs.setgid.v6.0\u0027 of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:\n  ceph: rely on vfs for setgid stripping\n  fs: move S_ISGID stripping into the vfs_*() helpers\n  fs: Add missing umask strip in vfs_tmpfile\n  fs: add mode_strip_sgid() helper\n",
  "tree_diff": []
}