Re: security bug in OProfile

[William C. <wc...@re...>]

John Levon wrote:
> On Tue, Feb 07, 2006 at 03:59:23PM +0000, Lu=EDs Miguel Silva wrote:
>=20
>=20
>>http://www.redhat.com/magazine/012oct05/features/oprofile/
>>http://devforums.amd.com/lofiversion/index.php/t359.html
>>https://www.redhat.com/archives/fedora-devel-java-list/2005-March/msg00=
117.html
>>https://uimon.cern.ch/twiki/bin/view/FIOgroup/LxbuildInfo
>>http://prospect.sourceforge.net/
>=20
>=20
> I don't think we can be held responsible for what other people recommen=
d.
>=20
>=20
>>PS2: i dont really understand your agressive response. It is quite
>>obvious that whoever did that opcontrol script tried to correct the
>>security bug i mentioned by exporting a "safe" PATH on the
>>script...(however...it should be about 2 lines sooner ;oP).
>=20
>=20
> As I mentioned I'd welcome a patch to fix this particular problem.
> However, no security audit has been done and I'm afraid I don't agree
> that auditing a shell script is easy. This is why we won't recommend
> using problematic features like sudo until somebody trustworthy does
> this audit.
>=20
> (And I suspect the audit would only make sense for the GUI, not the
> shell script.)
>=20
>=20
>>PS4: as you can see, even a article on the official redhat site
>>mentions the use of 'sudo'.
>=20
>=20
> This isn't Red Hat's project, though.
>=20
> regards,
> john

Looking at the questionable line in opcontrol I realize why that was in=20
there in the first place. opcontrol needs to use oprofiled and ophelp.=20
If someone used --prefix and installed it in a non-standard place=20
another versions of ophelp and oprofiled might used. The script is=20
suppose to use the ophelp and oprofiled in the same directory as=20
opcontrol.  Would having a full path to which and dirname be sufficient=20
to fix this problem like the attached patch?

-Will