Re: adduser default for sgid home directories
On Wed, 27 Jul 2022 16:10:18 +0200, Wouter Verhelst wrote: >On Mon, Jul 25, 2022 at 07:06:59PM +0200, Marc Haber wrote: >> I don't like the idea of messing with old NEWS entries at all. > >I'm trying to understand why you feel this way. It feels like rewriting history. Maybe the similiarity of the format to debian/changelog AND the fact that the same tool is used to edit supports that. [correct rationale snipped] Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: adduser default for sgid home directories
On Mon, Jul 25, 2022 at 07:06:59PM +0200, Marc Haber wrote:
> I don't like the idea of messing with old NEWS entries at all.
I'm trying to understand why you feel this way.
A NEWS.Debian entry is not aimed towards developers; it is meant as
documentation shown to the user when upgrading. Having apt-listchanges
tell you "We changed X to Y" immediately followed by "Oh actually, we
changed Y to Z" (or "Y back to X", as the case may be) is quite
confusing in that context, and could therefore be counterproductive.
I feel that NEWS.Debian should always be edited in such a way that
expected upgrade paths show our users the information they would need to
keep things running, and not (much) more than that. This means that if
the information in a NEWS.Debian file has become outdated, it should be
updated so that users upgrading from the package version they are
running get the most relevant information for their situation.
If people need to investigate how a package changed over time, then
there are other tools (debian/changelog, snapshot.debian.org, and a git
log if one is available) to achieve this. I don't think NEWS.Debian is
the right place to keep that type of information.
Am I missing something?
> In this case, an exception might be warranted, but we need to have the
> long explanation somewhere in the package for the next round of this
> issue that is expected in the 2030ies.
It absolutely makes sense to document decisions for future people
looking at the problem, but I'm not convinced that a long explanation
for historic decisions belongs in the NEWS.Debian file. The changelog
would seem to be a more appropriate location, or perhaps a
debian/README.why-we-do-things-this-way file could be created. Of
course, a NEWS.Debian entry should still contain the bits of information
that are relevant for the user who's upgrading the package, possibly
duplicating information if necessary.
Thanks,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: adduser default for sgid home directories
On Mon, 25 Jul 2022 09:05:55 -0700, Josh Triplett wrote: >Matt Barry wrote: >> On Mon, 2022-07-25 at 14:37 +0100, Colin Watson wrote: >> > On Sun, Jul 24, 2022 at 12:34:31PM -0400, Matt Barry wrote: >> > > Anyway, its been released at this point, so the issue is moot :) >> > >> > Regardless of the rest of the discussion, this isn't entirely true. >> > Yes, people following unstable will have already seen the NEWS entry >> > and >> > apt-listchanges won't show it again for that version, but it's still >> > possible to edit it retroactively so that (for example) people >> > upgrading >> > between stable releases see improved text. That can sometimes be >> > worthwhile. >> > >> >> That is a good point, and probably something we should plan to do. > >In particular, it may make sense to edit this NEWS entry and the >previous one, to avoid presenting two entries to stable users for two >different successive changes, rather than just one effective change. I don't like the idea of messing with old NEWS entries at all. In this case, an exception might be warranted, but we need to have the long explanation somewhere in the package for the next round of this issue that is expected in the 2030ies. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: adduser default for sgid home directories
Matt Barry wrote: > On Mon, 2022-07-25 at 14:37 +0100, Colin Watson wrote: > > On Sun, Jul 24, 2022 at 12:34:31PM -0400, Matt Barry wrote: > > > Anyway, its been released at this point, so the issue is moot :) > > > > Regardless of the rest of the discussion, this isn't entirely true. > > Yes, people following unstable will have already seen the NEWS entry > > and > > apt-listchanges won't show it again for that version, but it's still > > possible to edit it retroactively so that (for example) people > > upgrading > > between stable releases see improved text. That can sometimes be > > worthwhile. > > > > That is a good point, and probably something we should plan to do. In particular, it may make sense to edit this NEWS entry and the previous one, to avoid presenting two entries to stable users for two different successive changes, rather than just one effective change.
Re: adduser default for sgid home directories
On Mon, 2022-07-25 at 14:37 +0100, Colin Watson wrote: > On Sun, Jul 24, 2022 at 12:34:31PM -0400, Matt Barry wrote: > > Anyway, its been released at this point, so the issue is moot :) > > Regardless of the rest of the discussion, this isn't entirely true. > Yes, people following unstable will have already seen the NEWS entry > and > apt-listchanges won't show it again for that version, but it's still > possible to edit it retroactively so that (for example) people > upgrading > between stable releases see improved text. That can sometimes be > worthwhile. > That is a good point, and probably something we should plan to do. signature.asc Description: This is a digitally signed message part
Re: adduser default for sgid home directories
On Sun, Jul 24, 2022 at 12:34:31PM -0400, Matt Barry wrote: > Anyway, its been released at this point, so the issue is moot :) Regardless of the rest of the discussion, this isn't entirely true. Yes, people following unstable will have already seen the NEWS entry and apt-listchanges won't show it again for that version, but it's still possible to edit it retroactively so that (for example) people upgrading between stable releases see improved text. That can sometimes be worthwhile. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: adduser default for sgid home directories
On Mon, 2022-07-25 at 09:33 +0200, Bjørn Mork wrote: > Philipp Kern writes: > > On 25.07.22 08:46, Bjørn Mork wrote: > > > > > > obviously false. "No change" is always less surprising than any > > > change, > > > whatever the rationale is. > > > > It can also be unsurprising from an end-user's perspective. For > > someone new to the system. So that line of argument does not really > > hold. > > True. Good point. > > I was reading this as "unsuprising to the reader (system operator)", > but > I see that it could mean "unsusprising to the system users". Which > would make more sense. I apologize for the ambiguity; I did mean primarily for the end-user, who would likely a) assume their documents are private, and b) not expect any setgid weirdness. It is also unsurprising for users of other distributions, perhaps, which mostly use 0700. I take your point about any change being surprising.. but we wouldn't need a NEWS entry for that ;) > Is there a limit to the size of these entries which makes it hard to > be > more precise? None; this announcement was actually quite long. But the feedback is appreciated. Cheers, Matt signature.asc Description: This is a digitally signed message part
Re: adduser default for sgid home directories
Philipp Kern writes: > On 25.07.22 08:46, Bjørn Mork wrote: >> Matt Barry writes: - why has a change been made >>> >>> I think this is explained in excruciating detail. The short version >>> (from NEWS): >>> >>> "mode 0700 provides both the most secure, unsurprising default" > [...] >> And the claim that this is "most unsurprising" (less surprising?) is >> obviously false. "No change" is always less surprising than any change, >> whatever the rationale is. > > It can also be unsurprising from an end-user's perspective. For > someone new to the system. So that line of argument does not really > hold. True. Good point. I was reading this as "unsuprising to the reader (system operator)", but I see that it could mean "unsusprising to the system users". Which would make more sense. Is there a limit to the size of these entries which makes it hard to be more precise? Bjørn
Re: adduser default for sgid home directories
On 25.07.22 08:46, Bjørn Mork wrote: Matt Barry writes: - why has a change been made I think this is explained in excruciating detail. The short version (from NEWS): "mode 0700 provides both the most secure, unsurprising default" [...] And the claim that this is "most unsurprising" (less surprising?) is obviously false. "No change" is always less surprising than any change, whatever the rationale is. It can also be unsurprising from an end-user's perspective. For someone new to the system. So that line of argument does not really hold. Kind regards Philipp Kern
Re: adduser default for sgid home directories
Matt Barry writes: >> - why has a change been made > > I think this is explained in excruciating detail. The short version > (from NEWS): > > "mode 0700 provides both the most secure, unsurprising default" This is a self-referencing explanation. It provides no value. It's only good if you already understand (and agree) that 0700 is more secure. And the claim that this is "most unsurprising" (less surprising?) is obviously false. "No change" is always less surprising than any change, whatever the rationale is. Bjørn
Re: adduser default for sgid home directories
Hello, On Sun, 2022-07-24 at 15:09 +0100, RL wrote: > Marc Haber writes: > > > ... Here is what the adduser team considers possible > > documentation for this, and we itend to include this in NEWS.Debian > > as a > > rationale for the change. > > As a user who reads NEWS.Debian (via apt-listchanges) i found the > text > didnt give me the answers i was looking for. I wanted to know: It is a bit long, but this discussion has come up a number of times over the years, so for the people interested in the details, we felt it was better to have a well-documented rationale. > > - what had changed (and when) This was the first line of the NEWS. "The default for DIR_MODE has been set to 0700 for this release. Detailed explanation follows." So: there is the change; no need to keep reading unless you're interested in the details. > - why has a change been made I think this is explained in excruciating detail. The short version (from NEWS): "mode 0700 provides both the most secure, unsurprising default" > - how the change might affects my existing/new systems - eg do i need > to > manually do something to adopt it? > - how/if i can customise/revert/use the new changes? > For the vast majority of users, nothing needs to be changed. If you run a multi-user system, nothing about your existing users will change, but new users created with adduser will have the new permissions. If you do not want this, the method for changing it back is well documented. > I also found the end of the draft was written almost combatively - as > a > user i dont really care about bug reports or whether developers > argued > on a mailing list: i just want to know the facts and whether i need > to > do anything different as a result. A more neutral phrasing would be > better and would also go out-of-date slower. I am sorry you read it that way; as I said, we felt that an extended description of the change (and some of its history, for people wondering why this change is happening) was appropriate. Certainly no combativeness was intended. > > Most NEWS files suffer from this to some extent but i was hoping for > something with less about bug reports and more like: > > > "adduser version 3.122 has changed > pp (DIR_MODE setting in /etc/ ) from aaa to bbb (one of these > is > 0700 i think, but i couldnt tell which?). Respectfully, the NEWS is not THAT unclear. Perhaps a better opening would have been: The default mode for users created with adduser is now 0700. If you don't know what that means and/or don't know what the default was, you can ignore this change. (but that alone would leave questions unanswered, for people that have followed the issue) Anyway, its been released at this point, so the issue is moot :) -- Cheers, Matt signature.asc Description: This is a digitally signed message part
Re: adduser default for sgid home directories
Marc Haber writes: > ... Here is what the adduser team considers possible > documentation for this, and we itend to include this in NEWS.Debian as a > rationale for the change. As a user who reads NEWS.Debian (via apt-listchanges) i found the text didnt give me the answers i was looking for. I wanted to know: - what had changed (and when) - why has a change been made - how the change might affects my existing/new systems - eg do i need to manually do something to adopt it? - how/if i can customise/revert/use the new changes? I also found the end of the draft was written almost combatively - as a user i dont really care about bug reports or whether developers argued on a mailing list: i just want to know the facts and whether i need to do anything different as a result. A more neutral phrasing would be better and would also go out-of-date slower. Most NEWS files suffer from this to some extent but i was hoping for something with less about bug reports and more like: "adduser version 3.122 has changed pp (DIR_MODE setting in /etc/ ) from aaa to bbb (one of these is 0700 i think, but i couldnt tell which?). This change has been made to (prevent files being created with the wrong permissions? and also for compatibility with other distributions?) This means ccc (something about the root user's home directory and the user account made by the installer?). Administrators of existing systems may want to (manually chmod /root and other home directories under /home to 0700 for consistency with the new default? ) Administrators who want to have different behavior may (edit /etc/??? and set DIR_MODE back to ? and then restart some service? or do something else? )" Happy to help, but i really couldnt follow the draft below very clearly. I hope you see this as helpful and not annoying - i would be happy to help edit/send a patch etc when i understand the change. If you point me to some better documentation i will be happy to help further
adduser default for sgid home directories (was: Seeking consensus for some changes in adduser)
Back in March, I wrote in , https://lists.debian.org/debian-devel/2022/03/msg00304.html: > My post-discussion answer to question (1c) is yes, but I am still open > for arguments. If noone convinces me, the default for DIR_MODE will be > changed to 2700 (see (4) below). > > (...) > > A setgid bit on a non-group-readable directory might seem strange > though. Are there arguments against doing so aside from the ugly "S" in > ls output? We implemented that change last week, and promptly a bug report (#1014901) appeared, giving what we consider good arguments to change this back to 0700. Here is what the adduser team considers possible documentation for this, and we itend to include this in NEWS.Debian as a rationale for the change. Please comment. Suggested Documentation Text Follows: In adduser 3.122, we implemented code that allows setting the default for the mode bits of the home directory of a newly created system user independently of the mode bits of the home directory of a newly created non-system user (SYS_DIR_MODE vs DIR_MODE). This was in part done to finally solve #643559, which requested setting the sgid bit for the home directory of a non-system user by default, in order to ease setting access permissions of shared workspaces in multi-user systems. This default has oscillated back in forth in adduser multiple times since the 1990ies, because both ways to set this bit by default have advantages and disadvantages. After a preliminary request for comment (see https://lists.debian.org/debian-devel/2022/03/msg00098.html), the default value for DIR_MODE was changed to 2700 in adduser 3.122 (July 2022). Sadly, though the technical reasoning for NOT setting the bit have largely not survived the last two decades, here remain some use cases impacted by the change which we were not fully aware of. Promptly, #1014901 was filed, requesting that DIR_MODE be changed to 0700, effectively causing home directories of non-system users to be created without the sgid bit. The biggest point in the reasoning is that having the sgid bit set will need special measures to keep the home directory's group ownership from propagating to file system images, chroots, and archives, causing wrong file ownership/permissions in those entities, which in turn might propagate to different systems and cause security-related effects there. The bug report gives instructions to reproduce the behavior. System administrators who run multi-user environments which require shared workspaces have tools at their disposal to change the default behavior as their individual needs require, and likely are aware of how to work around any issues that arise as part of that configuration; it is also very possible that such systems may be managed using configuration management software. In an age of general purpose use on one end, and single purpose containers on the other, this is unlikely to be the majority of newly installed systems. So what remains is the decision to provide a sane default for a system that is installed by an end-user, who may not understand or be aware of this setting at all, but who still might use Internet HOW-TOs to build chroots, images or archives, inadvertently causing security issues on third-party systems. The clear and unsurprising solution is to leave the sgid bit for newly created users off by default. This is also important to keep the support effort for other packages down. Users surprised by the behavior might file bugs against other packages, increasing the effort necessary to support those other packages. In adduser 3.123, DIR_MODE will be changeed to 0700, flipping the default for the sgid bit once again to the value we have had for the majority of Debian's existence period. With this change, Debian is re-joining ranks again with ALL other major Linux distributions, none of which setting the sgid bit on home directories to 1 (research done in July 2022). As the root user and its home directory is created by other means, this primarily affects the one user that can be created in the Installer before there is any possibility to configure adduser. Those users will now again have the sgid bit of the home directory set to 0. Again, system administrators have the tools and documentation to configure their systems as their individual requirements dictate (using DIR_MODE, and/or fixing those initial directories). As mode 0700 provides both the most secure, unsurprising default, and is in line with most other major distributions, the adduser team considers the matter to be settled; any further discussion should come prepared with rationale, support, convincing use cases and a significant public discussion period. 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
