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. 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. -Dan