linux-kernel - Re: [PATCH v3] cpupower: Make help command available for custom install dir

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <a7e0810c-2d35-48c6-9140-1ebfa3edd660@linuxfoundation.org>
Date: Tue, 2 Jul 2024 12:57:10 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: Roman Storozhenko <romeusmeister@...il.com>
Cc: Thomas Renninger <trenn@...e.com>, Shuah Khan <shuah@...nel.org>,
 Javier Carrasco <javier.carrasco.cruz@...il.com>, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org, Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH v3] cpupower: Make help command available for custom
 install dir

On 7/2/24 12:52, Roman Storozhenko wrote:
> On Tue, Jul 2, 2024 at 9:40 AM Roman Storozhenko
> <romeusmeister@...il.com> wrote:
>>
>> On Mon, Jul 1, 2024 at 9:40 PM Shuah Khan <skhan@...uxfoundation.org> wrote:
>>>
>>> On 6/29/24 04:48, Roman Storozhenko wrote:
>>>> On Fri, Jun 28, 2024 at 9:45 PM Shuah Khan <skhan@...uxfoundation.org> wrote:
>>>>>
>>>>> On 6/28/24 05:30, Roman Storozhenko wrote:
>>>>>> On Thu, Jun 27, 2024 at 7:33 PM Shuah Khan <skhan@...uxfoundation.org> wrote:
>>>>>>>
>>>>>>> On 6/27/24 01:49, Roman Storozhenko wrote:
>>>>>>>> When the 'cpupower' utility installed in the custom dir, it fails to
>>>>>>>> render appropriate help info for a particular subcommand:
>>>>>>>> $ LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor
>>>>>>>> with error message like 'No manual entry for cpupower-monitor.1'
>>>>>>>> The issue is that under the hood it calls 'exec' function with
>>>>>>>> the following args: 'man cpupower-monitor.1'. In turn, 'man' search
>>>>>>>> path is defined in '/etc/manpath.config'. Of course it contains only
>>>>>>>> standard system man paths.
>>>>>>>> Make subcommands help available for a user by setting up 'MANPATH'
>>>>>>>> environment variable to the custom installation man pages dir. That
>>>>>>>> variable value will be prepended to the man pages standard search paths
>>>>>>>> as described in 'SEARCH PATH' section of MANPATH(5).
>>>>>>>
>>>>>>> What I am asking you is what happens when you set the MANPATH before
>>>>>>> running the command?
>>>>>>
>>>>>> It adds the custom search path to the beginning of the MANPATH variable.
>>>>>> I tested this case. All works as expected.
>>>>>>
>>>>>
>>>>> Let's try again. What happens if you run the command with MANPATH set and
>>>>> exported and then run the command. Can you send the output?
>>>>
>>>> hedin@...top:~/prj/cpupower/install/usr$ echo $MANPATH
>>>> /tmp/
>>>> hedin@...top:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/
>>>> bin/cpupower help monitor
>>>> ...................
>>>> man output
>>>> ...................
>>>> hedin@...top:~/prj/cpupower/install/usr$ echo $MANPATH
>>>> /tmp/
>>>> hedin@...top:~/prj/cpupower/install/usr$
>>>>
>>>
>>> Is this with your patch or mainline? Can you give cut and paste
>>> the man output here for the mainline coupower without your patch?
>>
>> The above output is from my patch.
>> This is the output from the mainline:
>> hedin@...top:~/prj/cpupower/install/usr$ sudo LD_LIBRARY_PATH=lib64/
>> bin/cpupower help monitor
>> [sudo] password for hedin:
>> No manual entry for cpupower-monitor
>> hedin@...top:~/prj/cpupower/install/usr$ echo $MANPATH
>> /tmp/
>> hedin@...top:~/prj/cpupower/install/usr$
>>
> Based on our today's conversation the following is the output for the mainline:
> 
> hedin@...top:~/prj/cpupower/install/usr$
> MANPATH="/home/hedin/prj/cpupower/install/usr/man:"
> LD_LIBRARY_PATH=lib64/ bin/cpupower help monitor
> hedin@...top:~/prj/cpupower/install/usr$ echo $MANPATH
> 
> .............
> man output
> .............
> 
> hedin@...top:~/prj/cpupower/install/usr$ export
> MANPATH="/home/hedin/prj/cpupower/install/usr/man:"
> hedin@...top:~/prj/cpupower/install/usr$ echo $MANPATH
> /home/hedin/prj/cpupower/install/usr/man:
> hedin@...top:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/
> bin/cpupower help monitor
> 
> .............
> man output
> .............
> 
> hedin@...top:~/prj/cpupower/install/usr$ LD_LIBRARY_PATH=lib64/ sudo
> bin/cpupower help monitor
> [sudo] password for hedin:
> bin/cpupower: error while loading shared libraries: libcpupower.so.1:
> cannot open shared object file: No such file or directory
> 
> As you can see we can use MANPATH for correct help invocation, unless
> we call it with 'sudo'. I can guess that it simply
> inherits the environment variables from the root shell that contains
> no 'MANPATH' variable set with an ordinary user.
> 

sudo -s will inherit the environment. Check sudo man page.

> Worth mentioning this in an appropriate manpage?

I don't think so.

thanks,
-- Shuah