On 20/11/2022 17:16, Jon Turney wrote:
On 13/11/2022 12:47, Achim Gratz wrote:
The problem is actually a more knotty than you seem to think:
prominently ca-certificates and man-db get their knickers in a twist
when the group during post-install is different from the group of the
installed files
Christian Franke writes:
> Anything installed with "All Users" option should IMO be protected
> against modifications by any regular non-elevated user.
Yes.
> This is not the case if the RID=513 group ("HOST\None",
> "DOMAIN\Domain-Users") is used. Many upstream projects install
> directories
Jon Turney wrote:
On 20/11/2022 19:05, Achim Gratz wrote:
Jon Turney writes:
I believe that the intent of the code in setup is that there should
only be two modes:
USER: install "for me", with the users primary group
As I understand it, the intention here was that the user can have a
On 20/11/2022 19:05, Achim Gratz wrote:
Jon Turney writes:
I believe that the intent of the code in setup is that there should
only be two modes:
USER: install "for me", with the users primary group
As I understand it, the intention here was that the user can have a
"single user
On Nov 21 13:39, ASSI wrote:
> Corinna Vinschen writes:
> > The idea is that the installation tree has POSIXy permissions and
> > administrative users have the right to change stuff. The administrators
> > group is part of the user's token if the process has been started
> > elevated, so, to me,
Corinna Vinschen writes:
> The idea is that the installation tree has POSIXy permissions and
> administrative users have the right to change stuff. The administrators
> group is part of the user's token if the process has been started
> elevated, so, to me, this looks like a natural choice.
As I
On Nov 20 20:05, Achim Gratz wrote:
> Jon Turney writes:
> > I believe that the intent of the code in setup is that there should
> > only be two modes:
> >
> > USER: install "for me", with the users primary group
>
> As I understand it, the intention here was that the user can have a
> "single
Jon Turney writes:
> I believe that the intent of the code in setup is that there should
> only be two modes:
>
> USER: install "for me", with the users primary group
As I understand it, the intention here was that the user can have a
"single user installation" in a place that they have access to
On 13/11/2022 12:47, Achim Gratz wrote:
The problem is actually a more knotty than you seem to think:
prominently ca-certificates and man-db get their knickers in a twist
when the group during post-install is different from the group of the
installed files and I suspect some other packages will
Jon Turney writes:
> On 08/10/2022 17:56, Achim Gratz wrote:
>> I think that setup was essentially treating the install as "for this
>> user only" since it was created and maintained by a script that can't
>> affect that option and the fact it was also in group Adminsitroators
>> didn't actually
Jon Turney writes:
> On 08/10/2022 17:56, Achim Gratz wrote:
>> I think that setup was essentially treating the install as "for this
>> user only" since it was created and maintained by a script that can't
>> affect that option and the fact it was also in group Adminsitroators
>> didn't actually
On 08/10/2022 17:56, Achim Gratz wrote:
I think that setup was essentially treating the install as "for this
user only" since it was created and maintained by a script that can't
affect that option and the fact it was also in group Adminsitroators
didn't actually register until now.
Yeah, that
Jon Turney writes:
> On 03/10/2022 20:23, Achim Gratz wrote:
>> Jon Turney writes:
>>> This problem is with files created by setup, or by post-install scripts?
>> I think both, although the problematic symlinks were created through
>> alternatives.
>
> That's pretty baffling.
Even more baffling
On 03/10/2022 20:23, Achim Gratz wrote:
Jon Turney writes:
This problem is with files created by setup, or by post-install scripts?
I think both, although the problematic symlinks were created through
alternatives.
That's pretty baffling.
I don't see how any of those commits would change
Jon Turney writes:
> This problem is with files created by setup, or by post-install scripts?
I think both, although the problematic symlinks were created through
alternatives.
> (I'm not sure how these commits could have caused the former, if the
> latter then reverting 45d8e84e "Drop group
On 22/09/2022 18:14, Achim Gratz wrote:
The release_2.91 comes with another regression that still puzzles me.
In a nutshell, the three commits that deal with setting up the groups
during / after installation
2022-08-27 Jon Turney Drop setting root_scope as a side-effect of
The release_2.91 comes with another regression that still puzzles me.
In a nutshell, the three commits that deal with setting up the groups
during / after installation
2022-08-27 Jon Turney Drop setting root_scope as a side-effect of
read_mounts()
2022-08-16 Jon Turney
17 matches
Mail list logo
