Your message dated Thu, 21 Jul 2022 06:48:58 +0000 with message-id <e1oepzw-0000gz...@fasolo.debian.org> and subject line Bug#1014901: fixed in adduser 3.123 has caused the Debian Bug report #1014901, regarding Home directories should not be setgid by default to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1014901: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014901 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---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
--- End Message ---
--- Begin Message ---Source: adduser Source-Version: 3.123 Done: Marc Haber <mh+debian-packa...@zugschlus.de> We believe that the bug you reported is fixed in the latest version of adduser, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1014...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Marc Haber <mh+debian-packa...@zugschlus.de> (supplier of updated adduser package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Format: 1.8 Date: Thu, 21 Jul 2022 08:10:13 +0200 Source: adduser Architecture: source Version: 3.123 Distribution: unstable Urgency: medium Maintainer: Debian Adduser Developers <addu...@packages.debian.org> Changed-By: Marc Haber <mh+debian-packa...@zugschlus.de> Closes: 1014450 1014901 Changes: adduser (3.123) unstable; urgency=medium . [ Marc Haber ] * flip default for DIR_MODE to 0700 again. Thanks to Josh Triplett (Closes: #1014901) * add debian.NEWS entry to document the DIR_MODE change * remove superficial examples/adduser.local.conf.examples/adduser.conf . [ Matt Barry ] * Check explicitly for <= 32 byte names. (Closes: #1014450) Checksums-Sha1: b47cbb933182d7efa366aa512ddbf7a52fad8b8a 1683 adduser_3.123.dsc 97ec8e8a5a57d830bb9feffa7bfdfb80e68d87a8 231624 adduser_3.123.tar.xz f7f15bf52927702d31e40012a723ca5ea7744e60 5697 adduser_3.123_source.buildinfo Checksums-Sha256: cf3508f50a329b1a892d5d1fb1bb87c4a66ab8b4958b81d34723d6cb45a188d5 1683 adduser_3.123.dsc e1befb7845dcfb240946e1016ca44c82f80fa9672ed44f2f22ab97dd4a0f5af4 231624 adduser_3.123.tar.xz c5f6dc4deccafed81db379b35a83536670d3f0116a670038d4f04fc0faaff27e 5697 adduser_3.123_source.buildinfo Files: c2ac6c6ea1f9fde1ebf6994a81023b8b 1683 admin important adduser_3.123.dsc 4f19886b30edbb2b97b6f7558a6bd742 231624 admin important adduser_3.123.tar.xz 65796ea828a6f9cf5d0d7bced4b8fbdc 5697 admin important adduser_3.123_source.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE6QL5UJ/L0pcuNEbjj3cgEwEyBEIFAmLY7roACgkQj3cgEwEy BEJiFhAAp/bivlRUgL02T1fhl9tdG2+ZszOGvITkIZzC+7Gm0qs2vAPUiLGVwCXl xsgZ0yGI6QouPG8vkcfSaXxnmB4Y5FJNdyiPzOhC107SUUxOQ/olqwi5Z2CzrJ/P nWQtoPA3Rcum4UhNRrtu1dE0M5CFLn8vgaYKzLPYfxP/auKHui3JOAidSB/5opv2 d3hpYl+VePsdkCGJTMEJ5Znf5TJGXXjNIpVk4Nokv9KSejVacIrknCrj/hTdVYAe 7/c3qn0fNPmDSVGfqK5BNi0nHYZ611Cj7LqBHJWVmpJIFv60B8W+n+tP2bW7LgSc Nh013nyUF16h7mXOlUPW7GYFRtBDbhSG0N4u2Dsojj3oq5dnj7swA+o9vPlQGy7m SquZ2eWkD6DkWqnHYC/JXjbXvF+MtvyzouTS+hg1nefCTFgLSe4+FjlVsHH17bfM e0gAnCpVc6HFG6Oei/wRhicdDpQs/9qU/KjPVPjvIxqeCvsKp3XR3BmWUr7EgSp0 hTcYT2pFUXnzF2LTlF39Xn2eVmsrQiEINBxwmE8C4Sqz6pYY4tnxhfevj09xmy5b 20RM7ji6LfD4T22jOvvE4SSU7Wntu9XWoRvc0DDUm2WuUHPR8+hK/ReIDX1TAQwz Zbr1S8Spk20gJTHelnEdpG7TrFll84wxirN98XMeczVFVAaqPjs= =Tsmt -----END PGP SIGNATURE-----
--- End Message ---
