Bug 425810

None of these are runnable by normal users unless you know the root password
(or, in some instances, are logged into the console):

$ ls -l /usr/bin/ | grep helper
lrwxrwxrwx  1 root root           13 2007-11-10 16:36 authconfig -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 authconfig-gtk ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:36 authconfig-tui ->
consolehelper
-rwxr-xr-x  1 root root         8184 2007-10-16 06:45 consolehelper
-rwxr-xr-x  1 root root        31056 2007-10-16 06:45 consolehelper-gtk
lrwxrwxrwx  1 root root           13 2007-11-20 19:11 cpufreq-selector ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:49 dateconfig -> consolehelper
lrwxrwxrwx  1 root root           13 2007-05-25 15:41 eject -> consolehelper
lrwxrwxrwx  1 root root           13 2007-12-07 20:03 gdmsetup -> consolehelper
-rwxr-xr-x  1 root root        12014 2007-10-29 16:35 gnc-fq-helper
lrwxrwxrwx  1 root root           22 2007-11-27 08:29 gnome-system-log ->
/usr/bin/consolehelper
lrwxrwxrwx  1 root root           13 2007-12-03 17:47 gparted -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:34 halt -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 kbdrate -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:50 liveinst -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:49 neat -> consolehelper
lrwxrwxrwx  1 root root           13 2007-12-07 20:05 pirut -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 pm-hibernate -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 pm-powersave -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 pm-restart -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 pm-shutdown -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 pm-suspend -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:34 poweroff -> consolehelper
lrwxrwxrwx  1 root root           13 2007-12-07 20:05 pup -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:34 reboot -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-15 14:09 repoman -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-21 00:26 revisor -> consolehelper
lrwxrwxrwx  1 root root           13 2007-12-11 21:28 selinux-polgengui ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:40 serviceconf -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:35 setup -> consolehelper
lrwxrwxrwx  1 root root           13 2007-12-07 20:05 system-cdinstall-helper ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37
system-config-authentication -> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:51 system-config-boot ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:49 system-config-date ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:51 system-config-display ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-12-16 00:11 system-config-firewall ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:44 system-config-keyboard ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 system-config-language ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:50 system-config-lvm ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 system-config-network ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 system-config-network-cmd
-> consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:50 system-config-printer ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:40 system-config-rootpassword
-> consolehelper
lrwxrwxrwx  1 root root           13 2007-12-16 00:11
system-config-securitylevel -> consolehelper
lrwxrwxrwx  1 root root           13 2007-12-11 21:28 system-config-selinux ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:40 system-config-services ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 system-config-soundcard ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:49 system-config-time ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-11-10 16:37 system-config-users ->
consolehelper
lrwxrwxrwx  1 root root           13 2007-12-07 20:05 system-install-packages ->
consolehelper
lrwxrwxrwx  1 root root           22 2007-11-21 00:26 virt-manager ->
/usr/bin/consolehelper

If you have an extension for mock, why dont you post it?

We can either, a) drop it in upstream mock along with unit tests so we know it
wont break, or at the very least b) help upstream maintainers know what you are
doing so that we can try to avoid breaking you. 

And, finally, mock 0.8.x's lifetime is going to be only another month or so. We
are going to be migrating F7 and F8 to use mock 0.9.x in the coming weeks (as
rawhide has already been migrated.)

Mock 0.9.x uses consolehelper in the exact same way as all the utilities in
comment #1. (ie. you are still going to be broken.)

(In reply to comment #1)
> None of these are runnable by normal users unless you know the root password
> (or, in some instances, are logged into the console):

Well, I am not talking applications being really run-able by normal users, I am
talking about (configure-) scripts being able to check whether an application is
potentially being run-able (i.e. carries +x permissions)

Technically, I am not referring to users being able to run
/usr/bin/xxx
but them to be able to 
test -x /usr/bin/xxx && echo "I can run it"

The way /usr/bin/mock currently is implemented users can't even check for mock's
version (mock --version) nor can they check for what this "crazy trojan with
this freaking permissions yum implanted on my system" is doing, because they
can't run mock --help.

More generally speaking, I consider all apps normal users can't run to be
mal-designed.

(In reply to comment #2)
> If you have an extension for mock, why dont you post it?
I don't have an extension for mock, I have local rpms which work with mock, such
as packages containing my local repos *.cfg's, wrapper scripts around
/usr/bin/mock etc. They aren't of much use for the general public.

The way you currently are setting up permissions, you even prevent me from being
able to setup my packages correctly.

(In reply to comment #3)
> Mock 0.9.x uses consolehelper in the exact same way as all the utilities in
> comment #1. (ie. you are still going to be broken.)
Then you better fix this.

(In reply to comment #3)
> Mock 0.9.x uses consolehelper in the exact same way as all the utilities in
> comment #1. (ie. you are still going to be broken.)
Additional question: Won't this render using private installations of mock
impossible? (E.g. users downloading mock*tar.gz and installing them to
$(HOME)/mock)?

In response to #4:

Unix permissions have a long and storied history dating back over 30 years now,
and are *the* method of DAC.

In this specific case (limited to mock <= 0.8.x), /usr/bin/mock IS NOT SAFE TO
RUN BY UNTRUSTED GENERAL USERS. The unix DAC model is explicitly designed to
handle this situation... take away execute permissions to untrusted users (ie.
'other').

The advantage this gives is that any knowledgeable admin can *grant* access to
this executable by using the 'chmod' command. As delivered by the distribution
RPMs, though, this is not a wise policy decision, since IT IS KNOWN THAT THIS IS
UNSAFE.

Your answer to this is likely to be that either /usr/bin/mock or mock.py should
check the user belongs to a certain group before executing anything except
--help or --version. This is not acceptable because it A) takes away the
previously-mentioned flexibility of using 'chmod' to let the site-admin decide
who they want to be able to execute it, and B) is more code in a security
sensitive area.

Your comments about trojans, etc, are really a whole lot of handwaving. "rpm -qi
mock", "rpm -qd mock" and "man mock" give all the information a user might need.
Additionally, a somewhat clueful user would see that r-sr-x--- root mock 
/usr/bin/mock *probably* means that they need to be in the 'mock' group to run mock.

In the end I think it is a non-argument to complain that mock 0.8 uses unix
permissions in the fashion in which they were originally designed to be used.

In response to #5:

The new scheme in 0.9 in no way breaks private builds.

You can install it where-ever you please, and run mock with 'sudo'. I explicitly
added support to mock to be run using either 'consolehelper' or 'sudo' in the
last two or three versions.

The consolehelper/sudo combination is *much* more flexible/secure than the old
mock <= 0.8 method.

A) no files delivered by mock are setuid

B) you can directly run "/usr/sbin/mock" using either consolehelper (as packaged
for fedora: /usr/bin/mock symlink to consolehelper), or using 'sudo'

C) You can install in an alternate location and run using consolehelper or sudo

D) You can directly run ./py/mock.py from the build tree using sudo.

In fact, (D) is how we implement the new unit test framework.

(In reply to comment #6)
> Unix permissions have a long and storied history dating back over 30 years
> now, and are *the* method of DAC.
Right, and they have been abused in various ways.

Avoiding to expose lack of usability such trickery to normal users are among the
reasons why libexec, /sbin, /usr/sbin etc. have been introduced.

You could easily implement a wrapper application /usr/bin/mock which handles
command-line processing and redirects suid tricks to another application say
/usr/libexec/mock/bin/mock.

> Your answer to this is likely to be that either /usr/bin/mock or mock.py should
> check the user belongs to a certain group before executing anything except
> --help or --version. This is not acceptable because it A) takes away the
> previously-mentioned flexibility of using 'chmod' to let the site-admin decide
> who they want to be able to execute it, and B) is more code in a security
> sensitive area.
I read this as: the approach the mock package has taken sufferes from
limitations, it can't provide a minimal amount of usability for /usr/bin/mock.

> Your comments about trojans, etc, are really a whole lot of handwaving. "rpm -qi
> mock", "rpm -qd mock" and "man mock" give all the information a user might need.

Rpm is not at all important here. We are talking about an arbitrary application
called mock, users should be able to install on arbitrary OSes with or without a
package management system in effect. The fact they can retrieve the required
information about what an application might be doing from other sources but the
application itself (app --help, man app), such as package managers is irrelevant.

You forgot to attach your patch.

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.