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] [thread-next>] [day] [month] [year] [list]

Date: Sat, 29 Jun 2024 12:48:05 +0200
From: Roman Storozhenko <romeusmeister@...il.com>
To: Shuah Khan <skhan@...uxfoundation.org>
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
Subject: Re: [PATCH v3] cpupower: Make help command available for custom
 install dir

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$

Just in case, the following is the output of the debugging session showing
how the 'MANPATH' looks like just before calling 'exec':

Breakpoint 2, print_man_page (subpage=0x7fffffffe1cb "monitor") at
utils/cpupower.c:84
84      {
(gdb) n
89              if (!subpage)
(gdb) n
93              subpage_len += strlen(subpage);
(gdb) n
95              page = malloc(subpage_len);
(gdb) n
96              if (!page)
(gdb) n
99              sprintf(page, "cpupower");
(gdb) n
100             if ((subpage != NULL) && strcmp(subpage, "help")) {
(gdb) n
101                     strcat(page, "-");
(gdb) n
102                     strcat(page, subpage);
(gdb) n
106             if (readlink("/proc/self/exe", exec_path, PATH_MAX) > 0) {
(gdb) n
107                     exec_dir = strdup(exec_path);
(gdb) n
108                     if (!exec_dir) {
(gdb) n
117                     man_env = getenv("MANPATH");
(gdb) n
118                     if (asprintf(&man_path, "%s/../man:%s",
(gdb) n
120                             setenv("MANPATH", man_path, 1);
(gdb) n
121                             free(exec_dir);
(gdb) p man_path
$1 = 0x55555556db20 "/home/hedin/prj/cpupower/install/usr/bin/../man:/tmp/"
(gdb) c
Continuing.
process 26122 is executing new program: /usr/bin/man


>
> thanks,
> -- Shuah
>
>
>


-- 
Kind regards,
Roman Storozhenko