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
