[Bug 1873785] Re: Root can't modify files of other users in directories with sticky bit anymore

[Steve Langasek]

See also the discussion on ubuntu-devel about this behavior change:
https://lists.ubuntu.com/archives/ubuntu-devel/2020-February/040904.html

** Tags added: ff-incoming

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1873785

Title:
  Root can't modify files of other users in directories with sticky bit
  anymore

Status in procps package in Ubuntu:
  New

Bug description:
  Hello,

  in Focal the behaviour has changed when a program running as root
  tries to modify a file which belongs to a user/group other than root
  in a directory with sticky bit set.

  I'm not sure if this is a bug or the behaviour is intentional (for
  certain security reasons).

  Steps to reproduce:

  - Boot current Focal daily iso
  - Open terminal
  - Create a directory with sticky bit set (chmod o+t; or use an existing directory with sticky bit, e.g. /var/crash )
  - Create an empty file with user:group set to anything different than root (e.g. ubuntu:ubuntu, ubuntu:whoopsie, ...)
  - Open the file with nano running as root (sudo nano testfile.txt), write something in it, and try to save it. This won't work and gives a "permission denied" error message.

  This behaviour is different than in previous Ubuntu versions. In Eoan
  it is possible to modify the file as root in the scenario described
  above.

  I discovered this because after changing my main installation to Eoan
  I noticed that I got weird error messages from rsync when backing up
  my root subvolume. In my backup script rsync runs as root, and can't
  update backed up contents of /var/crash or /var/spool/cups/tmp anymore
  because it isn't allowed to modify the respective files anymore.

  For me personally this is a regression compared to previous Ubuntu
  versions where I never saw such errors during backup.

  Whether PAM is the appropriate package to report this bug against I'm
  not sure, so please feel free to assign it to the correct package.

  If this is intentional, does anybody have a clue how to work around
  this for use cases like backup with rsync?

  Kind regards,
  Jan

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libpam-runtime 1.3.1-5ubuntu4
  ProcVersionSignature: Ubuntu 5.4.0-24.28-generic 5.4.30
  Uname: Linux 5.4.0-24-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Mon Apr 20 12:11:32 2020
  InstallationDate: Installed on 2020-04-08 (11 days ago)
  InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200408)
  PackageArchitecture: all
  SourcePackage: pam
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1873785/+subscriptions