On Fri, Jul 29, 2011 at 1:26 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Jul 28, 2011 at 6:14 PM, Seblu <seblu@seblu.net> wrote:
On Sat, Jun 18, 2011 at 5:30 PM, Seblu <seblu@seblu.net> wrote:
On Sat, Jun 18, 2011 at 5:34 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Sure, checking for root privileges for all actions is the easiest and simplest method. However, the status actions which currently, in most cases, can done as a regular user will require root privileges from now on if we go this way.
Yes. We speak of about 23 packages where a rc.d script should be corrected about status.
cd /var/abs && grep -ril '/etc/rc.d/functions' *|xargs grep --color 'status)'|wc -l
I'm ready to propose an updated version of this 23 rc.d script, if there is a workload isssue.
I have another (better, IMO) idea: enforce root privilege for all actions except status. Pros: - no hardcoded list
you can see status as a list of 1 element ;)
- regular users will still need be able to do: /etc/rc.d/foo status
For the few packages that currently require root privilege for the status action, we can argue that they are misusing the status function as they don't follow the daemon prototype /usr/share/pacman/rc-script.proto which has: status) stat_busy "Checking $daemon_name status"; ck_status $daemon_name ;; which doesn't need root privilege. So their current status function should be renamed to info, for example.
This would imply simply adding the following to /etc/rc.d/functions :
need_root() { (( $EUID != 0 )) && printf 'You need to be root.\n' && exit 1 }
if [[ "$1" != 'status' ]]; then need_root fi
Doesn't forget, /etc/rc.d/functions are sourced by others script than rc.d scripts. For example /var/abs/extra/ifplugd/ifplugd.action which doesn't have $1 the same meaning as your code expect.
Even if your solution is a compromise, I think in the case of status (23 pkg in the official repo), there is no need to make an exception to do things well.
Tom / Dave / Thomas have you an opinion?
Dave, Tom, i see your comments in this bug : https://bugs.archlinux.org/task/25271 and this doesn't make be happy.
Here I wanted to make adjustments while maintaining the will to implement this bug. As i said from the begining, maybe we cannot want to do that...
There is making adjustments, and there are regressions. Regressions are unacceptable, especially in core software like init and daemon scripts as well as network configuration.
I agree, release with a regression is unacceptable. To don't have regressions during introduction of checking rootiness in rc.d scripts we shoud have: 1) check that everyone wants this feature and this implementation 2) introduction NEED_ROOT=0 and need_root function in a core release 3) ask to maintainer of rc.d scripts which want to use as non root to update 5) set NEED_ROOT=1 in a testing release. 6) fix scripts we are still broken
Everyone gets the "why" here. We're just not satisfied with the implementation, or "how", as it broke things and is done in a file that should be source-able without side effects.
/etc/rc.d/functions is not a function which can be sourcable without side effects by non rc.d scripts because: - it's not a config files (so they can execute things) - PATH is changed (your program path will change) - LOCALES are reseted (your program locales will be in locale C) - checks are done on first arg so i can resume by : it's expected to be sourced by rc.d scripts _only_. That's why i think, if we choose to implement this kind of restriction, functions is a good place. But netcfg, seems to used this file (i missed it).
From a little grep on my station only netcfg source it as a program .
-- Sébastien Luttringer www.seblu.net