On Fri, Jul 29, 2011 at 1:32 AM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Jul 29, 2011 at 1:14 AM, Seblu <seblu@seblu.net> wrote:
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...
I just added a quick fix for this release (essentially a revert), we can figure out what to do properly for the next release.
I think we'll have to turn the logic on its head. By default we should only block things we know are always ok to block (like Eric's original patch, we could maintain a list of actions that always need root), or things which the rc script author has checked are ok to block (the inverse of how it is now, it should be possible to opt-in for requiring root).
This way we cannot get regressions in user-created scripts or scripts that just happen not to have been updated. It would be better not to check at all than to do a check that is useless in most cases. If rc.d maintainers wants to check rootitude, he can already do it. He don't need a patch in initscripts.
An why check rootitude, some user can have capatiblities to run it without be the root.
Remember that a false positive (trying to do something that requires root) is always fine, as the call will fail. However, a false negative (blocking something which does not need root) is not ok as it is essentially a regression in functionality as Dan points out.
That's a wise consideration. But regression is a word we give to a modification which go in a bad direction. By example, verbosity of kernel, complex network setups in initscripts was removed. This is also regression. But we accept it because we choose it. If we choose that initscripts must be run by root (this was the request) exept if it claim the opposit and we let times to have all scripts ready for this. This is still a regression for you? -- Sébastien Luttringer www.seblu.net