From: William C. <wc...@nc...> - 2002-09-30 14:54:21
|
Here are some features that I think would make oprofile more useful and reduce the need to have root privileges. Comments about them? That ability to do the analysis of profiling data on a separate machine. This could be implemented by having a command "op_environment" that will build a directory tree of the executables associated with each sample in the sample directory. All analysis programs will have a "-R" (root) option to indicate the starting directory for the executable search. This will allows archiving of the data and executables for future analysis on the data collection machine evening if the executables have been changed. It will also allow the data to be moved to another machine for analysis. This could be very useful for tracking down problems in the analysis tools. A script that a normal user could run to start default profiling, e.g. time based profiling using the RTC or CPU_CLOCK_UNHALTED. The script would only start the profiling if not profiling was running. It would not change the profiling if it was already in operation. Have the owner and group of the sample file be the same owner and group as the executable. This would allow the users to clear out the sample files that they were no longer wanted. Make oprof_start have a lock, so only one copy of oprof_start runs at a time. On shared systems this would be useful and prevent multiple users from unknowning changing the profiling system of another user. -Will |
From: Philippe E. <ph...@wa...> - 2002-09-30 19:14:18
|
William Cohen wrote: > Here are some features that I think would make oprofile more useful > and reduce the need to have root privileges. Comments about them? > > That ability to do the analysis of profiling data on a separate > machine. This could be implemented by having a command > "op_environment" that will build a directory tree of the executables > associated with each sample in the sample directory. All analysis > programs will have a "-R" (root) option to indicate the starting > directory for the executable search. This will allows archiving of > the data and executables for future analysis on the data collection > machine evening if the executables have been changed. It will also > allow the data to be moved to another machine for analysis. This could > be very useful for tracking down problems in the analysis tools. ok, but what about this implementation: $ op_session -R --session-name a_name will save under the session a_name the tree of binary file and during the copy of samples file modify their names by prepending $OPROF_DIR/session-name to all sample file so there is no need of a -R option for post-profile tools.I think user will find this way more usefull. After all we already have op_session and I think backup of binary file should imply backup of sample files. Can you look if there is no flaw here ? > > A script that a normal user could run to start default profiling, > e.g. time based profiling using the RTC or CPU_CLOCK_UNHALTED. The > script would only start the profiling if not profiling was running. It > would not change the profiling if it was already in operation. John ? op_start/oprof_start would be changed to don't allow to kill the current profiling session ? It's annoying for a single user system and I suspect than most of people use oprofile on such system. See later about configure option. For the user/root problem oprof_start is intended to be sudoed after installing but that's not documented. TODO: o audit oprof_start for security + document sudo ^^^^ someone enough experimented to review oprof_start code at security point of view ? iirc John fix the most proeminent security hole but we need an audit > Have the owner and group of the sample file be the same owner and > group as the executable. This would allow the users to clear out the > sample files that they were no longer wanted. iirc John and me disagree on that.I wanted to disallow any access to root samples files for simple user but John think is is very usefull to do that. Perhaps a configure option for that will be usefull. For now we should ecide what to put in TODO file and let people immplement what they want. > > Make oprof_start have a lock, so only one copy of oprof_start runs at > a time. On shared systems this would be useful and prevent multiple > users from unknowning changing the profiling system of another user. perhaps disallow to kill a running profile session is sufficient. regards, Phil |
From: William C. <wc...@nc...> - 2002-09-30 19:54:48
|
Philippe Elie wrote: > William Cohen wrote: > >> Here are some features that I think would make oprofile more useful >> and reduce the need to have root privileges. Comments about them? >> >> That ability to do the analysis of profiling data on a separate >> machine. This could be implemented by having a command >> "op_environment" that will build a directory tree of the executables >> associated with each sample in the sample directory. All analysis >> programs will have a "-R" (root) option to indicate the starting >> directory for the executable search. This will allows archiving of >> the data and executables for future analysis on the data collection >> machine evening if the executables have been changed. It will also >> allow the data to be moved to another machine for analysis. This could >> be very useful for tracking down problems in the analysis tools. > > > ok, but what about this implementation: > > $ op_session -R --session-name a_name > > will save under the session a_name the tree of binary file and > during the copy of samples file modify their names by prepending > $OPROF_DIR/session-name to all sample file so there is no need > of a -R option for post-profile tools.I think user will find this > way more usefull. > > After all we already have op_session and I think backup of > binary file should imply backup of sample files. > > Can you look if there is no flaw here ? What happens when the samples and executables are moved to another machine or a different user's directory? This is quite likely when things are tar'ed up and moved to another machine. Assuming that everything is always going to be $OPROF_DIR is not a good assumption. Not everyone want to put things in that location. In many cases it is more convienent to unpack the files in the users local directory. It would be better to minimize the requirement that everything has to be in $OPROF_DIR. Prepending $OPROF_DIR to each and every filename is the wrong way to go. However, backing up the samples and executables in one step is desirable. >> A script that a normal user could run to start default profiling, >> e.g. time based profiling using the RTC or CPU_CLOCK_UNHALTED. The >> script would only start the profiling if not profiling was running. It >> would not change the profiling if it was already in operation. > > > John ? op_start/oprof_start would be changed to don't allow to > kill the current profiling session ? It's annoying for a single > user system and I suspect than most of people use oprofile > on such system. See later about configure option. > > For the user/root problem oprof_start is intended to be sudoed > after installing but that's not documented. This user run default startup picks reasonable defaults for things. op_start makes no assumptions about what to do for profiling and the user still has to put in the events, sampling rates, etc. Think of this new command as a lowest common denominator for profiling on the machine and it will make the cheat sheet even simpler. To some extent this simple command is to allow multiple users to profile things at the same time with something that provides the at least the functionality of flat profiles in gprof. For the more interesting measurements there will still need to be some cooperations between users. > TODO: > o audit oprof_start for security + document sudo > ^^^^ > > someone enough experimented to review oprof_start code > at security point of view ? iirc John fix the most > proeminent security hole but we need an audit > > >> Have the owner and group of the sample file be the same owner and >> group as the executable. This would allow the users to clear out the >> sample files that they were no longer wanted. > > > iirc John and me disagree on that.I wanted to disallow any access > to root samples files for simple user but John think is is very > usefull to do that. Perhaps a configure option for that will be > usefull. Why do you not want users to have control of the data to their executables? I would like to understand your reasons. > For now we should ecide what to put in TODO file and let people > immplement what they want. > >> >> Make oprof_start have a lock, so only one copy of oprof_start runs at >> a time. On shared systems this would be useful and prevent multiple >> users from unknowning changing the profiling system of another user. > > > perhaps disallow to kill a running profile session is sufficient. oprof_start really needs a lock to make sure that two oprof_start processes are not running at the same time. oprof_start isn't designed to run with multiple copies. There are problems with status reporting (incorrect interrupt rates) when multiple oprof_start are running. -Will |
From: John L. <le...@mo...> - 2002-09-30 20:10:14
|
On Mon, Sep 30, 2002 at 03:45:14PM -0400, William Cohen wrote: > What happens when the samples and executables are moved to another > machine or a different user's directory? This is quite likely when > things are tar'ed up and moved to another machine. Assuming that > everything is always going to be $OPROF_DIR is not a good assumption. > Not everyone want to put things in that location. In many cases it is > more convienent to unpack the files in the users local directory. It > would be better to minimize the requirement that everything has to be in > $OPROF_DIR. Prepending $OPROF_DIR to each and every filename is the > wrong way to go. I agree. We need to see how this fits in pp_interface. > This user run default startup picks reasonable defaults for things. We must be careful to not allow any DoS problem. > op_start makes no assumptions about what to do for profiling and the > user still has to put in the events, sampling rates, etc. Think of this > new command as a lowest common denominator for profiling on the machine > and it will make the cheat sheet even simpler. To some extent this > simple command is to allow multiple users to profile things at the same > time with something that provides the at least the functionality of flat > profiles in gprof. For the more interesting measurements there will > still need to be some cooperations between users. I'm OK with this, I suppose. The whole userspace tools need a serious shake up. > >iirc John and me disagree on that.I wanted to disallow any access > >to root samples files for simple user but John think is is very > >usefull to do that. Perhaps a configure option for that will be > >usefull. > > Why do you not want users to have control of the data to their > executables? I would like to understand your reasons. If the user can read the original executable, they should be able to read the sample file. > oprof_start really needs a lock to make sure that two oprof_start > processes are not running at the same time. oprof_start isn't designed > to run with multiple copies. There are problems with status reporting > (incorrect interrupt rates) when multiple oprof_start are running. I do not like the auto-reset behaviour of the interrupt rates anyway. regards john |
From: Philippe E. <ph...@wa...> - 2002-09-30 21:27:57
|
John Levon wrote: > On Mon, Sep 30, 2002 at 03:45:14PM -0400, William Cohen wrote: > > >>What happens when the samples and executables are moved to another >>machine or a different user's directory? This is quite likely when >>things are tar'ed up and moved to another machine. Assuming that >>everything is always going to be $OPROF_DIR is not a good assumption. >>Not everyone want to put things in that location. In many cases it is >>more convienent to unpack the files in the users local directory. It >>would be better to minimize the requirement that everything has to be in >> $OPROF_DIR. Prepending $OPROF_DIR to each and every filename is the >>wrong way to go. > > > I agree. We need to see how this fits in pp_interface. this don't work if user backup the whole session directory as pointed by Will, I'm thinking about replacing the path name suffix in samples filename with a path name suffix relative to the session directory.I mean removing the first "}" in samples filename. Another problem is if the user want to only backup a few binary because he know the other binary can't change. op_session would to allow specifying what binary it must save and change modify sample filename only for this binary.(but backup the whole samples dir anyway) regards, Phil |
From: Philippe E. <ph...@wa...> - 2002-09-30 21:38:04
|
Philippe Elie wrote: > John Levon wrote: > > this don't work if user backup the whole session directory as pointed > by Will, I'm thinking about replacing the path name suffix in samples > filename with a path name suffix relative to the session directory.I > mean removing the first "}" in samples filename. indeed this need some change in post profile tools.post_profile tools must use the directory location of session as current dir. Phil |