Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 510636 - sys-apps/openrc -> /lib/rc/sh/rc-cgroup.sh doesn't check permissions
Summary: sys-apps/openrc -> /lib/rc/sh/rc-cgroup.sh doesn't check permissions
Status: RESOLVED DUPLICATE of bug 500364
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: OpenRC Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-18 10:09 UTC by nobody
Modified: 2014-08-07 21:36 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
rc-cgroup-wperm.patch (rc-cgroup-wperm.patch,801 bytes, patch)
2014-06-10 05:19 UTC, Steve L
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description nobody 2014-05-18 10:09:36 UTC
Since the addition of rc-cgroup.sh openrc output is dirty because it doesn't check permissions and try blindly to execute commands it doesn't have rights to do.



Reproducible: Always

Steps to Reproduce:
/etc/init.d/anyservice status

Actual Results:  
LANG=C /etc/init.d/root status
/lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpu/tasks: Permission denied
/lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuset/tasks: Permission denied
/lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/devices/tasks: Permission denied
/lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/freezer/tasks: Permission denied
/lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/openrc/tasks: Permission denied
mkdir: cannot create directory '/sys/fs/cgroup/openrc/root': Permission denied
/lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpu/tasks: Permission denied
/lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuset/tasks: Permission denied
/lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/devices/tasks: Permission denied
/lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/freezer/tasks: Permission denied
/lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/openrc/tasks: Permission denied
mkdir: cannot create directory '/sys/fs/cgroup/openrc/root': Permission denied
 * status: started


Expected Results:  
 * status: started/crash... without all the mess

being a non authorized user to start or stop a service doesn't mean that user cannot check the status of the service and should get a nice output of its status as the user might then query the admin to change that status (restart/stop/start...)

sys-apps/openrc-0.12.4  USE="ncurses netifrc pam unicode -debug -newnet (-prefix) (-selinux) -static-libs -tools
Comment 1 Steve L 2014-06-10 05:19:48 UTC
Created attachment 378614 [details, diff]
rc-cgroup-wperm.patch

I can confirm this, though I also get cpuacct and debug cgroup errors (obviously config-dependent.)

cgroup_cleanup() is my code, though my copyright isn't on the file. Rest looks like stuff we discussed, though not all of it, and some of it not so well-written (wouldn't get past review in #bash, if you specify sh advice.)

Anyhow attaching trivial patch to fix this specific issue; without write permission this function can never work, so it makes perfect sense to check that pre-condition in the function for robustness.

The file needs a cleanup rewrite though. I can do that easily enough, though it's a bit disappointing the sh idioms for robustness I repeatedly outlined didn't make it through.

I have a feeling the logic may need review, as outlined in comment; as well as the whole sh codebase needing a cleanup, after reviewing commit history.
Comment 2 zlg (RETIRED) gentoo-dev 2014-07-15 10:47:23 UTC
I can confirm the mess spat out by `/etc/init.d/root status` as a non-root user, and that the single line added by Steve L (comment #1) fixes the cosmetic problem.

I'm running amd64 multilib stable, OpenRC version 0.12.4
Comment 3 William Hubbs gentoo-dev 2014-07-17 14:21:20 UTC
Actually this might be a dupe. Does anyone have any comments on the
solution in bug#500364?
Comment 4 William Hubbs gentoo-dev 2014-08-07 21:36:06 UTC

*** This bug has been marked as a duplicate of bug 500364 ***