Timothy Murphy wrote:
Jeff Vian wrote:
To me it is just one more piece of evidence
that whoever wrote this program did not think carefully enough
about what precisely the program is meant to do.
They did think carefully. The present usage handles probably at least
99+% of all cases.
Do you mean that system-config-printer sets up a printer correctly
in > 99% of cases?
Where do you get your figures from?
I have what I take to be a pretty standard system -
printer attached to the parallel port on my desktop,
and accessed from various laptops and other computers -
and none of the printer wizards has _ever_ worked for me
on any machine except the desktop itself.
The CUPS web interface on port 631 always works,
although the documentation is not very good, IMHO.
Even the Windows XP wizard works reasonably well.
The present config ensures that anyone running these programs (with
default paths/permissions) has root authority, and makes sure that the
program itself does not have to be SUID root. SUID root was the earlier
configuration, and is a security risk.
That seems perfectly sensible to me.
But I don't see why it requires you to have two different programs
with the same name.
consolehelper is a utility to add specific functionality to other
programs, namely the ability to prompt for the root password and run a
program as root. To add the functionality to a program "myprog", all[1]
you need to do is:
* install "myprog" in /usr/sbin (where it will be part of root's path
and hence root will run "myprog" directly without needing the help of
consolehelper)
* install a symlink /usr/bin/myprog -> consolehelper
The symlink in /usr/bin is in tha path of all regular users, so they
will get "consolehelper" when they run "myprog". consolehelper looks at
the name of the program it was called as ("myprog" in this example),
prompts for the root password, and runs the actual program myprog from
/usr/sbin
So there is *one* program "myprog" doing the actual work, and *one*
program "consolehelper" providing the "run as root" functionality. This
is surely a simpler, more elegant approach than having to code the "run
as root" functionality into dozens of different programs? It also makes
much more sense from a security viewpoint to have one version of the
"run as root" code rather than dozens of implementations in different
programs.
[1] there's a little more to do actually - see
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/s1-access-console-enable.html
Paul.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
