[Touch-packages] [Bug 1873785] Re: Root can't modify files of other users in directories with sticky bit anymore
Since you've identified a fix for your use case that doesn't require changing the sysctl setting, I am marking this 'wontfix'. It can be reopened if someone identifies other cases that warrant revisiting the question of reverting this setting. ** Changed in: procps (Ubuntu) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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: Won't Fix 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1873785] Re: Root can't modify files of other users in directories with sticky bit anymore
Steve, thanks for the hint to the discussion. So if I got this right, I could restore the behaviour of previous Ubuntu versions by setting fs.protected_regular=0. For my personal purpose of backing up files with rsync, I found out that I can also work around this by _not_ using the --inplace option of rsync in my backup script. It seems that I actually don't need to use this option for my usecase, and not using it seems to avoid the scenario where root has to write to files in sticky directories belonging to different users (instead rsync can just make an updated copy and delete the original file). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1873785] Re: Root can't modify files of other users in directories with sticky bit anymore
** Tags removed: ff-incoming ** Tags added: rls-ff-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1873785] Re: Root can't modify files of other users in directories with sticky bit anymore
This doesn't come from pam, but from procps / systemd which now set fs.protected_regular by default to block uid mismatches in sticky directories. See /usr/lib/sysctl.d/protect-links.conf. ** Package changed: pam (Ubuntu) => procps (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1873785] Re: Root can't modify files of other users in directories with sticky bit anymore
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 Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1873785] Re: Root can't modify files of other users in directories with sticky bit anymore
As additional information, I tested if using the Eoan kernel with Focal would do any difference on this - it didn't, so this seems not to be dependent on the kernel version in Focal. ** Description changed: 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 that root (e.g. ubuntu:ubuntu, ubuntu:whoospie, ...) + - 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) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam 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 pam 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 o