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
