[arch-projects] [initscripts][PATCH 2/2] rc.d: Add check to cleanly abort rc.d script if user doesn't have root privileges

[Seblu]

On Fri, Jul 29, 2011 at 1:26 AM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Thu, Jul 28, 2011 at 6:14 PM, Seblu <seblu at seblu.net> wrote:
>> On Sat, Jun 18, 2011 at 5:30 PM, Seblu <seblu at seblu.net> wrote:
>>> On Sat, Jun 18, 2011 at 5:34 AM, Eric Bélanger <snowmaniscool at 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