This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]