17 replies to this topic

[hmc]

Hi guys,

my libiconv problem is driving me nuts!
I'd kindly ask someone with some time on his hands and with decent PND knowledge to assist me sorting that out.

Situation is as follows:

My TrueCrypt PNDcontains a folder "lib", which contains libiconv.so.2.

The run script of the PND contains the code

LD_LIBRARY_PATH="./lib"
export LD_LIBRARY_PATH

But when I attempt to mount a TrueCrypt container, after entering the container password and then the user password, TrueCrypt claims that "libiconv.so.2" is not available!

I think this is a new problem in SuperZaxxon release 1.5. I think that in SuperZaxxon Beta5 this has worked. but I am not 100% sure about that.

Could anyone please help me? I am stuck with that problem now. :-(

Helping me would mean
- downloading the PND
- creating a truecrypt container to test with
- reproducing the error
- disassembling the PND
- analyzing the reason for the problem

This would be really great.

Thank you in advance!
Daniel

[mcobit]

If the folder is called ".lib" and you export ./lib, that won't work

[hmc]

sorry, no, the folder is called "lib" inside the PND.
Will correct this now in the first post

[mcobit]

Ok. What about exporting fullpath?

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mnt/utmp/truecrypt/lib

if it opens a new shell in the program and executes something from there, the setting could be lost, too.
Maybe you need to have a look at the program and how it executes this stuff.

[hmc]

full path doesn't help here. :-(

need sleep now. will continue tomorrow...

thanks anyway!
daniel

[Neelix]

I get the impression that the error message is not accurately reporting the problem.

According to lsof truecrypt is already successfully loading the library in question:

op-inigo:~$ lsof |grep "/mnt/utmp/TrueCrypt/libs"
truecrypt 2657 neelix  mem    REG	    7,2				   6 /mnt/utmp/TrueCrypt/libs/libiconv.so.2.5.1
truecrypt 2665 neelix  mem    REG	    7,2				   6 /mnt/utmp/TrueCrypt/libs/libiconv.so.2.5.1

- Neelix

[hmc]

Neelix, can you reproduce the problem?
What firmware are you testing on?

Yesterday I totally messed up my SuperZaxxon 1.5 SD install. Nothing worked anymore, and after rebooting I even got the error "Login program cannot be executed" or similar. So I now went back to Beta5, and there the same PND works flawlessly, and lsof also reports that libiconv.so.2.5.1 is loaded from the PND's lib directory.

However, on a clean Superzaxxon 1.5 install on NAND, the PND produces that error, so the problem does not have to do with the mess of yesterday.

I am totally confused.

mcobit's idea, that the program internally launches a new shell, which does not see the LD_LIBRARY_PATH, is now disproven by the fact that the same PND works on Beta5, right?


Is there any hypothetical reason, why maybe a binary compiled on Beta5 is not able to load a library (although it can locate it) on release 1.5?

Thanks for any hint or idea!


Daniel

[notaz]

That does not make sense, nobody changed library lists during the whole beta to final.

Maybe your beta5 has codecpack installed and in influences things somehow?

[hmc]

Codec pack was also installed on final install...

[Neelix]

I have not been able to get it to mount the encrypted volume, and I get exactly the same error message.

I'm testing on SuperZaxxon Beta 5a w/ codec pack, as I haven't got around to reflashing with SuperZaxxon Final yet.

mcobit's theory makes sense to me, as the dialog box seems to be spitting out whatever is sent to stderr including the usual
"We trust you have received the usual lecture from the local System Administrator." message if its the first time you've run sudo since boot.

- Neelix

[Neelix]

Aha! It looks like mcobit was right. The fact that its it calling sudo seems to be the cause of the issue.
I found the following on the sudo man-page:

Note that the dynamic linker on most operating systems will remove
variables that can control dynamic linking from the environment of
setuid executables, including sudo. Depending on the operating system
this may include _RLD*, DYLD_*, LD_*, LDR_*, LIBPATH, SHLIB_PATH, and
others. These type of variables are removed from the environment
before sudo even begins execution and, as such, it is not possible for
sudo to preserve them.

It also provides a workaround, but it will mean having to change the truecrypt source-code:

Environment variables to be set for the command may also be passed on
the command line in the form of VAR=value, e.g.
LD_LIBRARY_PATH=/usr/local/pkg/lib. Variables passed on the command
line are subject to the same restrictions as normal environment
variables with one important exception. If the setenv option is set in
sudoers, the command to be run has the SETENV tag set or the command
matched is ALL, the user may set variables that would overwise be
forbidden. See sudoers(5) for more information.

If I have understood this, and what little I have seen of the source code correctly then I believe it should just be a matter of adding some code to CoreService.cpp to getenv("LD_LIBRARY_PATH") and then adding an assignment for it to the arguments passed to sudo on line 362.

HTH

- Neelix

[hmc]

Neelix, thanks so much for this info! It sounds very plausible.

I need to sort out some firmware issues (SD-reinstall of release 1.5, because it's totally borked for some reason). Then I will try another method for onboard compiling and see, if this new method eliminates all these libiconv problems I had with compiling on Beta5. I hope it will.

If not, I will definitely try your suggestion with changing the call of sudo in CoreService.cpp.

Daniel

[hmc]

Hi Neelix,
as the build system change did not solve the libiconv issue for me, I now went to try your suggestion.

But unfortunately I did not have success yet.
Maybe someone with more understanding of execvp() can give me a hint?


I patched line 362 of CoreService.cpp this way:

const char *args[] = { "sudo", "-S", "-p", "", strcat("LD_LIBRARY_PATH=",getenv("LD_LIBRARY_PATH")), appPath.c_str(), TC_CORE_SERVICE_CMDLINE_OPTION, nullptr )

(so I added that LD_LIBRARY_PATH stuff behind '-p ""' paramter of sudo).

What I get now, when mounting a volume, is - as usual - the prompt for my user password, and once entered, I get the message "Failed to obtain administrator privileges".
I assume that the syntax is not correct in some way, but I don't know why.

Also, is there a way to check the exact command line execvp() assembles from the args[] array in line 363?:

execvp (args[0], ((char* const*) args));

Thank you for any hint!

Daniel

[Neelix]

Hi Daniel,

If I read that correctly you are effectively separating the -p option from its argument. (I don't believe that empty string has any effect.) Try putting it before -p.

EDIT: On second thought I don't think that's right. What happens now if you run it first thing after a reboot? Could you provide the exact text of the error dialog?

- Neelix

[hmc]

Hi Neelix,

tried with the LD_LIBRARY_LATH before the -p parameter, but it gave the same result.
Isn't the empty "" parameter after the -p the parameter of the -p parameter, i.e. an empty sudo prompt?
Anyway...
Here is the additional info you requested:

Booted, and then immediately executed the PND.
Mounted my volume.
entered the volume password:

 pan1sd0_2012-07-16_18-36-03.png   82.56K   15 downloads

Then I am asked for the administrator password:

 pan1sd0_2012-07-16_18-36-30.png   68.09K   21 downloads

I enter my user password.... OH, can this be the problem? Do I need to add truecrypt to a sudoers file or something, so this can work? Do we have an actual administrator password on the Pandora at all? But normally, when using sudo, I can enter my normal user password, and have admin rights.

Okay, back to reporting mode ;-)

I enter the user password, and this gives me this:

 pan1sd0_2012-07-16_18-36-48.png   75.23K   13 downloads

Any idea?...

Thank you!
Daniel

[M-HT]

Also, is there a way to check the exact command line execvp() assembles from the args[] array in line 363?:

execvp (args[0], ((char* const*) args));

Try something like this:

const char **arg;
arg = args;
while (*arg != nullptr)
{
    printf("%s ", *arg);
    arg++;
}
printf("\n");

[Neelix]

Hi Daniel,

tried with the LD_LIBRARY_LATH before the -p parameter, but it gave the same result.
Isn't the empty "" parameter after the -p the parameter of the -p parameter, i.e. an empty sudo prompt?
Anyway...

Yeah I figured that out shortly after posting, hence the edit. :-)

Here is the additional info you requested:

Booted, and then immediately executed the PND.
Mounted my volume.
entered the volume password:

Then I am asked for the administrator password:

I enter my user password.... OH, can this be the problem? Do I need to add truecrypt to a sudoers file or something, so this can work? Do we have an actual administrator password on the Pandora at all? But normally, when using sudo, I can enter my normal user password, and have admin rights.

I very much doubt it. As I understand it, entering your user password is exactly correct. Your user account is already given permission to use sudo, so there is no need for additional permission for truecrypt specifically.

I enter the user password, and this gives me this:

 pan1sd0_2012-07-16_18-36-48.png   75.23K   13 downloads

Any idea?...

To be honest... I think it's misreporting the error.

The fact that it was reporting the library failure to begin with tells me that it was succeeding at obtaining administrator privileges all along, but the program is assuming a privileges problem if it doesn't see the expected outcome for any reason.

The fact that the dialogue box is otherwise empty tells me that nothing is now being sent to stderr by the process being executed, which in turn suggests to me that the command is being executed correctly, but it isn't doing something that the program expects it to do.

I think It would be useful at this point to add code similar to what M-HT suggested to discover the text of the command line being executed. Once we know what it was trying to execute, we should then be able to trace where it is being called from and what the testing conditions are, and hopefully, what the actual effect of the command is.

Is it possible that it worked and reported the error anyway? Maybe there is a race condition and the execution of the command took longer than the program was expecting, so it reported failure? I'd suggest you try it again then type mount in a terminal, to see if the volume was in fact mounted.

- Neelix

[hmc]

Thanks Neelix and M-HT. Working on some other very time-consuming project currently, so this topic must wait until maybe tomorrow, maybe the weekend, for further investigation.
Will report back here, as soon as I have the time to continue!
Daniel