This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
setuid-branch merged to CVS head
- From: David Smith <dsmith at redhat dot com>
- To: Systemtap List <systemtap at sources dot redhat dot com>
- Date: Tue, 14 Aug 2007 10:51:14 -0500
- Subject: setuid-branch merged to CVS head
The work from the setuid-branch has been merged to CVS head. What does
this mean? This means that the next time you do a CVS update (or the
next time you pull a systemtap snapshot), you'll be pulling the code
that Martin Hunt and I have been working on.
This new code allows systemtap developers/users to run systemtap without
needing root access. To run the staprun program (which installs
systemtap kernel modules), a user must be now one of the following:
* the root user;
* a member of the 'stapdev' group; or
* a member of the 'stapusr' group. Members of the stapusr group can
only use modules located in the /lib/modules/VERSION/systemtap
directory (where VERSION is the output of "uname -r"). This
directory must be owned by root and not be world writable.
So, there are two classes of users: systemap developers (the root user
and members of the stapdev group) and systemtap users (members of the
stapusr group). Systemtap developers can compile and run any
systemtap script. Systemtap users can only run "approved"
pre-compiled modules located in /lib/modules/VERSION/systemtap.
For more details of the new security strategy, see the new file called
README.security.
So what do you need to do to run systemtap now as a systemtap developer?
At minimum you'll need to add the 'stapdev' user group to your system
("sudo groupadd -r stapdev"), add yourself into that group ("sudo
vigr"), then logout and back in to have 'stapdev' as one of your groups.
I've tested the new code on x86 fc7, x86 rhel5, x86_64 rhel5, and x86_64
rhel4. The testsuite results are exactly the same (with the lone
exception of the systemtap.samples/ioblocktest.stp test failing on x86
fc7 which I'm looking into).
There is one known problem if you plan on running the new code, then
switching back to an old snapshot - some of the new setup method will
cause an old release to fail. To fix this, unmount /sys/kernel/debug or
/mnt/relay (depending on the host OS) before trying to run an old release.
If anyone has questions, I'll be happy to try to answer them.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)