----- Original Message ----- > From: "Josh Boyer" <jwboyer@xxxxxxxxxxxxxxxxx> > To: "Discussions about development for the Fedora desktop" <desktop@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Wednesday, May 13, 2015 11:24:14 AM > Subject: Re: Fedora 22 update security > > On Wed, May 13, 2015 at 11:14 AM, Christian Schaller > <cschalle@xxxxxxxxxx> wrote: > > > > > > > > > > ----- Original Message ----- > >> From: "Josh Boyer" <jwboyer@xxxxxxxxxxxxxxxxx> > >> To: "Discussions about development for the Fedora desktop" > >> <desktop@xxxxxxxxxxxxxxxxxxxxxxx> > >> Sent: Wednesday, May 13, 2015 10:27:23 AM > >> Subject: Re: Fedora 22 update security > >> > >> On Wed, May 13, 2015 at 10:00 AM, Bastien Nocera <bnocera@xxxxxxxxxx> > >> wrote: > >> > > >> > > >> > ----- Original Message ----- > >> >> Actually that should not an issue since we only do offline updates, > >> >> so there is no chance of one user updating software while > >> >> another is using it. > >> > > >> > And only admin users can reboot the machine while other users are using > >> > it... > >> > >> Even in that scenario I'm don't believe allowing non-admin users to > >> apply updates is the correct thing to do. I mean, your friend is over > >> and turns on your laptop and logs into the non-admin account he > >> created. He sees updates and says to apply them (via offline updates > >> or not). He reboots the machine since he's the only logged in user. > >> Now you have a bunch of updates applied that you didn't know about the > >> next time you log in. > >> > >> This really seems like a bad idea to me. > >> > > Well I guess it comes down to who we design the default install experience > > towards. My take is that our primary target is people on single user system > > with the idea being that people in more complex setups would be installing > > using kickstarts and similar and thus be able to tweak the configuration > > of such systems to suit their requirements (what tooling we offer or lack > > of such > > for helping with such tweaking is another debate). > > > > So even in the single user scenario I can see that examples as the one you > > mentioned > > can happen, but I can't help but feel that the problem here is with your > > friend and > > not the system for assuming he should feel free to update your machine > > without > > asking you. > > We're going to have to disagree then. The problem isn't with a > friend. If the system allows a user with 0 privileges on the system > to potentially majorly change the system, it's a problem with the > system. I could come up with other scenarios involving kids using a > shared family laptop and terrible analogies about loaded guns with no > safety, but I'm trying to avoid hyperbole. > > > That said this is not a major issue to me as the default behaviour should > > be here > > that the first user created on a system should be in the wheel group (which > > we need > > to fix as this does not happen if you set up your user using Anaconda, but > > it is the case > > if you set up your user using the GNOME initial install wizard.) > > Sure, the default cases are all covered and mostly unimpacted because > the first user should be an admin. I agree. What I disagree with is > saying that is good enough and leaving the non-admin user hole around. > Put another way, changing the policy to prevent non-admin users from > applying updates does not impact the default Workstation setup while > making the system safer overall. I see no downside to making that > change. > > josh Yeah, although if we are going to make that change I we should do the change in Anaconda at the same time, ensuring that the first user account is in the wheels group. Or alternative if its simpler, just disable the account creation in Anaconda. Christian -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
