Re: [gentoo-dev] [PATCH] savedconfig.eclass: do not preserve symlink in restore_config
On Sun, 2023-06-04 at 20:46 +0200, Arsen Arsenović wrote: > > I believe that the target directory of this cp can be considered > equivalent in terms of access to any superuser-only directory, so I'm > not sure I see the problem with this change. It silently changes something that was safe (but stupid) to something unsafe (but still stupid).
Re: [gentoo-dev] [PATCH] savedconfig.eclass: do not preserve symlink in restore_config
Michael Orlitzky writes: > If so, the symlink should point to a superuser-only location to avoid > creating any new vulnerabilities. We can't fix the general problem, but > we could at least mention in the docs that symlinks will (now) be > followed and that users should be careful if they want to maintain the > files elsewhere. I believe that the target directory of this cp can be considered equivalent in terms of access to any superuser-only directory, so I'm not sure I see the problem with this change. LGTM -- Arsen Arsenović signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] savedconfig.eclass: do not preserve symlink in restore_config
On Sun, Jun 4, 2023 at 2:03 PM Michael Orlitzky wrote: > > On Sun, 2023-06-04 at 13:31 -0400, Mike Gilbert wrote: > > This allows users to maintain the saved config file in some other > > location. > > > > If so, the symlink should point to a superuser-only location to avoid > creating any new vulnerabilities. We can't fix the general problem, but > we could at least mention in the docs that symlinks will (now) be > followed and that users should be careful if they want to maintain the > files elsewhere. That seems self-evident to me, and I don't think it warrants a callout in the documentation.
Re: [gentoo-dev] [PATCH] savedconfig.eclass: do not preserve symlink in restore_config
On Sun, 2023-06-04 at 13:31 -0400, Mike Gilbert wrote: > This allows users to maintain the saved config file in some other > location. > If so, the symlink should point to a superuser-only location to avoid creating any new vulnerabilities. We can't fix the general problem, but we could at least mention in the docs that symlinks will (now) be followed and that users should be careful if they want to maintain the files elsewhere.
