On Thu, 14 Jul 2022 11:38:46 +0200 Marc Haber <mh+debian-packa...@zugschlus.de> 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, > <yjinpj6x3y9ra...@torres.zugschlus.de>. 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.
