Hell yes. Aside from the DoS it permits by filling the disk, it also massively increases security exposure. No longer can you allow users to have accounts on the box on the basis that you've uninstalled everything non-essential and you have confidence in the installed package set; you're now vulnerable to '''every''' local exploit in '''every''' package in '''every''' configured repository, as I understand it.

I might even add third-party repositories so that I can install one or two packages (like my printer driver) which aren't available in Fedora for various reasons -- and this would allow users to bring in any package from those repositories too, wouldn't it?

It was a stunningly bad idea to allow this in the first place.

My position: this is a bad idea indeed, and we should issue a security update which changes the policy to the same as in Fedora 11 (require root authorization once per user, allow keeping it indefinitely), that should strike the proper balance between convenience and security (it has always worked fine).

Replying to [comment:1 dwmw2]:

you're now vulnerable to '''every''' local exploit in '''every''' package in '''every''' configured repository, as I understand it.

How's this different from inserting a USB pendrive and running a program from that?

It was a stunningly bad idea to allow this in the first place.

In your opinion. In a "desktop" distribution it lets us fulfil some pretty important use cases like installing clipart and codecs.

Replying to [comment:2 kkofler]:

require root authorization once per user, allow keeping it indefinitely

That option is available in PolicyKit anymore, so it's not really an option.

Then PolicyKit 1 needs to be fixed urgently. It should have been obvious right from the start that supporting this is an essential requirement for it to be suitable as a replacement for the old PolicyKit. It's pretty sad that the new PolicyKit got rushed in without regards to regressions (see also the lack of a policy editor, which makes such bad defaults all the more scary).

Actually, I think this !PolicyKit 1 limitation can be worked around inside !PackageKit:
https://bugzilla.redhat.com/show_bug.cgi?id=534047#c141

Replying to [comment:3 rhughes]:

How's this different from inserting a USB pendrive and running a program from that?

You can't run programs from USB drives. The default mount options for automounted volumes include noexec. In fact, this is why the default mount options include noexec. Even if you try to destroy your system by (say) copying the program over to your home directory and setting it executable, modes such as setuid root won't be preserved. By contrast, when a package is installed, you do get the setuid root bits.

It's a really basic fact that executable files from system installed packages can do much more damage than executable files from external volumes. In fact, it concerns me that you don't realize the difference, since you're supposed to have thought of such things prior to making this decision. The clear implication is that this change was poorly thought out to begin with.

Replying to [comment:7 djao]:

Replying to [comment:3 rhughes]:

How's this different from inserting a USB pendrive and running a program from that?

You can't run programs from USB drives. The default mount options for automounted volumes include noexec. In fact, this is why the default mount options include noexec.

The options also include nodev and nosuid, which are imho much more important, because they remove any special privileges from the files. Which is something the policiy kit installation does not. A feature in package kit to allow users to install packages e.g. in their home directory, which then thanks to some overlay magic that needs to be written, allows them to use the programs for tasks that do not need extra privileges, would be something that could be allowed by default imho.

The most disturbing aspect of this change is it was not openly discussed beforehand. The vast majority of commenters on the bugzilla ticket agree that this is an extremely significant change in security policy. However, the developers who made this change either did not agree with this assessment, or did not care to discuss the matter openly with the larger community. In fact, they didn't even feel it necessary to mention this change in the release notes, much less make inform users of the required actions to reverse this change, until there was a public outcry. And unfortunately, at the time of this writing, the instructions in the release notes are incorrect.

What further disturbs me is the developer's dismissive, defensive and even hostile responses when questioned about these changes by others. However, I do realize this is something beyond the control of this committee.

All that said, I also believe that allowing non-privileged users to install software by default is very unwise, especially when the steps required to prevent this are anything but obvious.

This ticket is closed - an update was pushed.