Bug#1014901: Home directories should not be setgid by default
On Thu, Jul 14, 2022 at 04:20:18PM -0400, Matt Barry wrote: > On Thu, 2022-07-14 at 13:05 -0700, Josh Triplett wrote: > > The use case below, and any other tools that create files and know to > > set their permissions appropriately but don't expect unusual > > ownership > > by default: > > > > In particular, it is common to build various kinds of filesystem, > > > > container, or disk images, and to do so within your home > > > > directory. > > > > Users writing tools and scripts to build such images need to make > > > > sure > > > > to create files with an appropriate mode, but such scripts often > > > > assume > > > > (reasonably) that if they're running as root:root and they create > > > > a > > > > file, that file will be owned by root:root. Attempting to build > > > > filesystems, containers, disk images, or similar in an > > > > unexpectedly > > > > setgid directory will produce unexpected results (leaving aside > > > > that the > > > > directory mode itself will be surprising). > > Could you be just slightly more specific about a use case that fails? > Given how many times this has come up over the years, I'm trying to get > a sense of what the *actual* issues are (as opposed to what they used > to be). > > Enough instruction that I can reproduce a specific problem(s) would be > great. Sure. Here's a sample of the kind of script I regularly encounter, producing incorrect results in a setgid directory. The script expects to produce files owned by root:root, but the files and directories get the wrong group, and the setgid bit gets propagated to the constructed filesystem image. /tmp/testdir$ ls -ld drwxr-sr-x 2 josh josh 4096 Jul 16 13:40 . /tmp/testdir$ ls -l total 4 -rwxr-xr-x 1 josh josh 354 Jul 16 13:40 make-filesystem.sh /tmp/testdir$ cat make-filesystem.sh #!/bin/bash if [ "$(id -u)" -ne 0 ]; then echo Run as root >&2 exit 1 fi umask 022 mkdir fsroot fsroot/bin fsroot/etc fsroot/srv mkdir -m 0700 fsroot/srv/workdir echo 'nameserver 169.254.169.253' > fsroot/etc/resolv.conf printf '#!/bin/sh\necho example binary\n' > fsroot/bin/example chmod a+x fsroot/bin/example mke2fs -d fsroot root.img 16M /tmp/testdir$ sudo ./make-filesystem.sh mke2fs 1.46.5 (30-Dec-2021) Creating regular file root.img Creating filesystem with 16384 1k blocks and 4096 inodes Filesystem UUID: ec2c8666-96d9-4bce-b964-4c32ed098638 Superblock backups stored on blocks: 8193 Allocating group tables: done Writing inode tables: done Copying files into the device: done Writing superblocks and filesystem accounting information: done /tmp/testdir$ ls -l total 1196 drwxr-sr-x 5 root josh 4096 Jul 16 13:41 fsroot -rwxr-xr-x 1 josh josh 354 Jul 16 13:40 make-filesystem.sh -rw-r--r-- 1 root josh 16777216 Jul 16 13:41 root.img /tmp/testdir$ mkdir /tmp/testmount /tmp/testdir$ sudo mount -o loop root.img /tmp/testmount /tmp/testdir$ sudo ls -lR /tmp/testmount/ /tmp/testmount/: total 15 drwxr-sr-x 2 root josh 1024 Jul 16 13:41 bin drwxr-sr-x 2 root josh 1024 Jul 16 13:41 etc drwx-- 2 root root 12288 Jul 16 13:41 lost+found drwxr-sr-x 3 root josh 1024 Jul 16 13:41 srv /tmp/testmount/bin: total 1 -rwxr-xr-x 1 root josh 30 Jul 16 13:41 example /tmp/testmount/etc: total 1 -rw-r--r-- 1 root josh 27 Jul 16 13:41 resolv.conf /tmp/testmount/lost+found: total 0 /tmp/testmount/srv: total 1 drwx--S--- 2 root josh 1024 Jul 16 13:41 workdir /tmp/testmount/srv/workdir: total 0
Bug#1014901: Home directories should not be setgid by default
On Thu, Jul 14, 2022 at 01:05:51PM -0700, Josh Triplett wrote: > On Thu, 14 Jul 2022 11:38:46 +0200 Marc Haber > wrote: > > It is really sad that you didn't participate in the discussion in march, > > where this part of the changes didnt get much attention and noone came > > up with any arguments against sgid home directories. I personally am at > > a loss here since I am just a server jockey who doesn't have many > > unprivileged shell account users on my boxes. > > I'm not subscribed to -devel. I saw that some discussion about adduser > took place, and saw some of the topics, but I didn't see any mention of > sgid home directories. I would have been happy to participate in such a > discussion, had I known about it. The first I heard about this was via > apt-listchanges. :( Then at least apt-listchanges has done its job. I must admit that I rarely read what it offers. > > > One of the issues links to > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=64806 , which talks > > > about easing the setup of shared directories for users who don't feel > > > comfortable running `chmod 2770` or similar themselves. That seems like > > > a relatively small justification, given that anyone setting up a shared > > > work directory *can* run `chmod 2770` or similar themselves, and doing > > > so does not require any special permission. > > > > A local admin who doesn't like the behavior is free to change the > > default by setting an appropriate DIR_MODE in adduser.conf. There is a > > NEWS.Debian entry pointing the local administrator to this new behavior. > > I understand this, and I understand that there's no one default that > will make everyone happy. I'm hoping to make the case for what the > default should be, to both minimize surprises and minimize the impact on > the most users. I think you have the team almost convinced. I would appreciate if you could give more detaile examples, so that we can put less FUDdish rationale for the non-gid home directory in the docs? Matt has asked a few interesting questions on Thursday, and I would love to get feedback to them. > > > The more recent issue 643559 suggests that > > > > Those "bad side-effects", if they were ever relevant and important > > > > enough to make personal groups not work properly, have now been fixed. > > > > > > However, this is not the case; this change does in fact have bad > > > side-effects. This change breaks some common use cases that apply to > > > users on many systems, both single-user and multi-user. > > > > Can we please have more information than just "bad side-effects"? > > The use case below, and any other tools that create files and know to > set their permissions appropriately but don't expect unusual ownership > by default: I would like to have someting like "in an sgid directory, a deboostrap chroot will be broken because the frobnification will not work". > I'm also hoping to make a case for "this change is a surprise and a > regression, and changing it *back* shouldn't have the burden of > 'changing the default' but rather 'reverting this change and returning to the > previous default'". But either way, I'm willing to make the case > regarding the default itself. This default happened to have changed at least twice over the history of Debian. > > We can also talk to the ctte if the discussion on -devel doesn't bring > > any more consensus. > > I sincerely hope it doesn't come to that. I'd really like to have more advice from the ctte without having an actual dispute, more like an oracle or a Council of the Wise People. "On devel, noone seemed to really care either way" is often bad advice. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1014901: Home directories should not be setgid by default
Control: severity -1 serious Hi, we need to revisit that decision. I am inflating severity to block testing migration of this version until we have decided wat to do. Josh, can you give more concrete examples, typescripts, recipies to experience what happens with an sgid directory with images, archives etc to support is with the decision? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1014901: Home directories should not be setgid by default
Hi Josh, On Thu, 2022-07-14 at 13:05 -0700, Josh Triplett wrote: > > > The more recent issue 643559 suggests that > > > > Those "bad side-effects", if they were ever relevant and > > > > important > > > > enough to make personal groups not work properly, have now been > > > > fixed. > > > > > > However, this is not the case; this change does in fact have bad > > > side-effects. This change breaks some common use cases that apply > > > to > > > users on many systems, both single-user and multi-user. > > > > Can we please have more information than just "bad side-effects"? > > The use case below, and any other tools that create files and know to > set their permissions appropriately but don't expect unusual > ownership > by default: > > > In particular, it is common to build various kinds of filesystem, > > > container, or disk images, and to do so within your home > > > directory. > > > Users writing tools and scripts to build such images need to make > > > sure > > > to create files with an appropriate mode, but such scripts often > > > assume > > > (reasonably) that if they're running as root:root and they create > > > a > > > file, that file will be owned by root:root. Attempting to build > > > filesystems, containers, disk images, or similar in an > > > unexpectedly > > > setgid directory will produce unexpected results (leaving aside > > > that the > > > directory mode itself will be surprising). Could you be just slightly more specific about a use case that fails? Given how many times this has come up over the years, I'm trying to get a sense of what the *actual* issues are (as opposed to what they used to be). Enough instruction that I can reproduce a specific problem(s) would be great. (If it makes sense to take this part to -devel, please feel free.) > > > > Would it help to do this kind of work in a subdirectory under the > > home > > directory and making sure that one is not setgid? I am happy to > > document > > this. > > That's certainly a workaround if you know it's a problem. On the > other > hand, it's likewise possible for anyone doing shared-work-directories > on > a multiuser system to create a directory that *is* setgid. > > I fully acknowledge here that there's no one default that will make > everyone happy, and that someone is going to end up needing to > configure > it. I'm attempting to make the case for what the default should be. > > I'm also hoping to make a case for "this change is a surprise and a > regression, and changing it *back* shouldn't have the burden of > 'changing the default' but rather 'reverting this change and > returning to the > previous default'". But either way, I'm willing to make the case > regarding the default itself. The previous conversation on -devel would have been the best point at which to identify this as a regression (or indeed, to document any downsides). My personal choice of defaults align with neither the current nor the previous config; if it is to keep changing, the setting should really have some consensus. Cheers, Matt
Bug#1014901: Home directories should not be setgid by default
On Thu, 14 Jul 2022 11:38:46 +0200 Marc Haber wrote: > On Wed, Jul 13, 2022 at 11:45:58PM -0700, Josh Triplett wrote: > > adduser 3.122 changes home directories to be setgid by default. The > > issues discussing that change mention use cases involving multiuser > > systems with shared groups, though that doesn't explain setting this > > mode on home directories rather than on shared work areas. > > This was part of the big adduser discussion debian-devel@l.d.o and > didn't get much attention. The setting is run-time configurable in > adduser.conf. > > I would be willing to re-raise the severity of this issue if I can find > a case for changing the default AGAIN and there is some discussion on > debian-devel on this topic. [...] > It is really sad that you didn't participate in the discussion in march, > where this part of the changes didnt get much attention and noone came > up with any arguments against sgid home directories. I personally am at > a loss here since I am just a server jockey who doesn't have many > unprivileged shell account users on my boxes. I'm not subscribed to -devel. I saw that some discussion about adduser took place, and saw some of the topics, but I didn't see any mention of sgid home directories. I would have been happy to participate in such a discussion, had I known about it. The first I heard about this was via apt-listchanges. :( > > One of the issues links to > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=64806 , which talks > > about easing the setup of shared directories for users who don't feel > > comfortable running `chmod 2770` or similar themselves. That seems like > > a relatively small justification, given that anyone setting up a shared > > work directory *can* run `chmod 2770` or similar themselves, and doing > > so does not require any special permission. > > A local admin who doesn't like the behavior is free to change the > default by setting an appropriate DIR_MODE in adduser.conf. There is a > NEWS.Debian entry pointing the local administrator to this new behavior. I understand this, and I understand that there's no one default that will make everyone happy. I'm hoping to make the case for what the default should be, to both minimize surprises and minimize the impact on the most users. > > The more recent issue 643559 suggests that > > > Those "bad side-effects", if they were ever relevant and important > > > enough to make personal groups not work properly, have now been fixed. > > > > However, this is not the case; this change does in fact have bad > > side-effects. This change breaks some common use cases that apply to > > users on many systems, both single-user and multi-user. > > Can we please have more information than just "bad side-effects"? The use case below, and any other tools that create files and know to set their permissions appropriately but don't expect unusual ownership by default: > > In particular, it is common to build various kinds of filesystem, > > container, or disk images, and to do so within your home directory. > > Users writing tools and scripts to build such images need to make sure > > to create files with an appropriate mode, but such scripts often assume > > (reasonably) that if they're running as root:root and they create a > > file, that file will be owned by root:root. Attempting to build > > filesystems, containers, disk images, or similar in an unexpectedly > > setgid directory will produce unexpected results (leaving aside that the > > directory mode itself will be surprising). > > Would it help to do this kind of work in a subdirectory under the home > directory and making sure that one is not setgid? I am happy to document > this. That's certainly a workaround if you know it's a problem. On the other hand, it's likewise possible for anyone doing shared-work-directories on a multiuser system to create a directory that *is* setgid. I fully acknowledge here that there's no one default that will make everyone happy, and that someone is going to end up needing to configure it. I'm attempting to make the case for what the default should be. I'm also hoping to make a case for "this change is a surprise and a regression, and changing it *back* shouldn't have the burden of 'changing the default' but rather 'reverting this change and returning to the previous default'". But either way, I'm willing to make the case regarding the default itself. > > Given those tradeoffs, I don't think this change is the right default. > > I'd like to ask that the default mode be reverted from 2700 to 700. > > I'd like you to take this discussion to debian-devel, most desireably as > reply to https://lists.debian.org/debian-devel/2022/03/msg00304.html, > . I can do that. > We can also talk to the ctte if the discussion on -devel doesn't bring > any more consensus. I sincerely hope it doesn't come to that.
Bug#1014901: Home directories should not be setgid by default
Control: -1 severity wishlist On Wed, Jul 13, 2022 at 11:45:58PM -0700, Josh Triplett wrote: > adduser 3.122 changes home directories to be setgid by default. The > issues discussing that change mention use cases involving multiuser > systems with shared groups, though that doesn't explain setting this > mode on home directories rather than on shared work areas. This was part of the big adduser discussion debian-devel@l.d.o and didn't get much attention. The setting is run-time configurable in adduser.conf. I would be willing to re-raise the severity of this issue if I can find a case for changing the default AGAIN and there is some discussion on debian-devel on this topic. > One of the issues links to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=64806 , which talks > about easing the setup of shared directories for users who don't feel > comfortable running `chmod 2770` or similar themselves. That seems like > a relatively small justification, given that anyone setting up a shared > work directory *can* run `chmod 2770` or similar themselves, and doing > so does not require any special permission. A local admin who doesn't like the behavior is free to change the default by setting an appropriate DIR_MODE in adduser.conf. There is a NEWS.Debian entry pointing the local administrator to this new behavior. > The more recent issue 643559 suggests that > > Those "bad side-effects", if they were ever relevant and important > > enough to make personal groups not work properly, have now been fixed. > > However, this is not the case; this change does in fact have bad > side-effects. This change breaks some common use cases that apply to > users on many systems, both single-user and multi-user. Can we please have more information than just "bad side-effects"? > In particular, it is common to build various kinds of filesystem, > container, or disk images, and to do so within your home directory. > Users writing tools and scripts to build such images need to make sure > to create files with an appropriate mode, but such scripts often assume > (reasonably) that if they're running as root:root and they create a > file, that file will be owned by root:root. Attempting to build > filesystems, containers, disk images, or similar in an unexpectedly > setgid directory will produce unexpected results (leaving aside that the > directory mode itself will be surprising). Would it help to do this kind of work in a subdirectory under the home directory and making sure that one is not setgid? I am happy to document this. > Given those tradeoffs, I don't think this change is the right default. > I'd like to ask that the default mode be reverted from 2700 to 700. I'd like you to take this discussion to debian-devel, most desireably as reply to https://lists.debian.org/debian-devel/2022/03/msg00304.html, . We can also talk to the ctte if the discussion on -devel doesn't bring any more consensus. It is really sad that you didn't participate in the discussion in march, where this part of the changes didnt get much attention and noone came up with any arguments against sgid home directories. I personally am at a loss here since I am just a server jockey who doesn't have many unprivileged shell account users on my boxes. -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1014901: Home directories should not be setgid by default
Package: adduser Version: 3.122 Severity: normal X-Debbugs-Cc: j...@joshtriplett.org adduser 3.122 changes home directories to be setgid by default. The issues discussing that change mention use cases involving multiuser systems with shared groups, though that doesn't explain setting this mode on home directories rather than on shared work areas. One of the issues links to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=64806 , which talks about easing the setup of shared directories for users who don't feel comfortable running `chmod 2770` or similar themselves. That seems like a relatively small justification, given that anyone setting up a shared work directory *can* run `chmod 2770` or similar themselves, and doing so does not require any special permission. The more recent issue 643559 suggests that > Those "bad side-effects", if they were ever relevant and important > enough to make personal groups not work properly, have now been fixed. However, this is not the case; this change does in fact have bad side-effects. This change breaks some common use cases that apply to users on many systems, both single-user and multi-user. In particular, it is common to build various kinds of filesystem, container, or disk images, and to do so within your home directory. Users writing tools and scripts to build such images need to make sure to create files with an appropriate mode, but such scripts often assume (reasonably) that if they're running as root:root and they create a file, that file will be owned by root:root. Attempting to build filesystems, containers, disk images, or similar in an unexpectedly setgid directory will produce unexpected results (leaving aside that the directory mode itself will be surprising). This is not just a matter of "change the configuration on your system"; this is a support issue for many, many users who run such tools or who work with others who do so. I really do not look forward to adding this to my library of "if something is broken, check this" issues (and, likely, not remembering it immediately as a possibility about another developer's system, having long since fixed my own). Both of these are valid use cases, and I'm not going to suggest that either one is invalid. However, I think having setgid home directories is *more surprising* behavior, and addresses a less common use case at the expense of a more common one. The default behavior of a Linux system is that file creation uses the current user and group, and setgid home directories are a surprise. Perhaps most importantly, the failure mode of the multiuser case is much more obvious and easy to debug. You go to work in a shared area, on a multiuser interactive system, a file has the wrong permission, you change it with chmod/chgrp. Because the system is interactive and the failure mode is noticed by an interactive user as a permission issue, it's easy to diagnose and fix and causes relatively little hiccup. By contrast, the failure mode of the filesystem/image/container creation case can be much harder to debug, and can manifest as "this image I created isn't booting on a remote system, which has no users and no shells and no remote access, and it's failing before it gets logging/tracing up because things have the wrong ownership, so there's no obvious cause". Nothing necessarily points to ownership/permissions right away, and it's *not* encountered by an interactive user with an obvious error message. Given those tradeoffs, I don't think this change is the right default. I'd like to ask that the default mode be reverted from 2700 to 700. - Josh Triplett
