getenv("HOME") returns "/root" with "sudo" - c++

I'm writing a program on my Raspberry Pi that requires the function "getenv("HOME")" to locate "/home/pi".
However, since I'm using the "wiringPi" library that requires "sudo" to run, "getenv("HOME")" now returns "/root" as the HOME directory instead of "/home/pi".
Is there a way to locate "/home/pi" with "getenv("HOME")" while using "sudo" the run the program?
Any help will be appreciated. Thank you.

Transferring comments and response into an answer.
If you know the answer is /home/pi, why do you need getenv("HOME") to get the wrong value?
It's because getenv("HOME") is the code from another library I am trying to run, which I cannot change.
Presumably, calling setenv("HOME", "/home/pi", 1) is a bit too much like cheating, too?
setenv("HOME", "/home/pi", 1) works for me.
Why are you sure that the value you need is /home/pi? Why isn't /root correct when the program is run by root (or someone running sudo)?
This becomes mostly immaterial given that there's another unchangeable library involved.
In that case, setting the correct value for the environment variable before invoking the other library is a mostly reasonable mechanism.

Related

how is the build order of kernel by Wince 6.0

I've changed the file "handle.c" in winceos\COREOS\nk\kernel.. and need to build according to take the changes into the core.dll for nk.bin
is there any build order to follow to avoid to build the hole solution?
First, let me say that making that change where you did is a bad, bad idea. Never change the public or private trees directly. If Microsoft issues a QFE that changes that code, when you apply the QFE, your changes will be overwritten and without warning. Always clone the code and change the clone.
As far as making kernel changes without having to rebuild the entire project, the answer is no, you can't. Changes in the code potentially change addresses, and a vast amount of the OS is fixed up with those addresses during the build process. You'll have to rebuild the entire thing after a change like that (as opposed to, for example, drivers which you can build individually without rebuilding the entire OS).
thanks for your answer.
what I found now by trying myself is yes, it's possible by doing "build & sysgen" of "winceos" folder under PRIVATE.
The change execution on kernel code was just adding a RETAILMSG to see the HANDLE count.
The file handle.c create handle table and give handles. There is a number of commands creating/allocating handle. I do not really know, by which handle requests the kernel calls handle.c(??), but it "can" for some developers be usefull to be able to manuplate it??
But in summary, doing "build & sysgen"+"MakeRunTimeImage" makes the changes on kernel valid.
I did it on "PRIVATE/winceos", but perhaps it's also possible by doing iy more locally, for example on PRIVATE/winceos/COREOS/nk/kernel folder. I didn't tried it ;)

wxWidgets wxConfBase Write very slow

I'm using wxConfBase to save the data of my text box. (windows)
config = new wxConfig(wxT("soft"));
config->Write(wxT("COM"),temp_port->GetValue());
config->Write(wxT("SQL_HOST"),mainset_sql_host->GetValue());
config->Write(wxT("SQL_DB"),mainset_sql_db->GetValue());
config->Write(wxT("SQL_LOGIN"),mainset_sql_login->GetValue());
config->Write(wxT("SQL_PASS"),mainset_sql_pass->GetValue());
{.......}
delete config;
I call that on my closing function.
The fact is that it's extremely slow, takes about 10 secs (program freezed) to write about 20 param.
I believe it's write on my local disk, as i've not been able to find out where the hell is that saved, even trying using config->SetPath.
Also the access to the files on my computer doesn't seems to be that slow...
Also maybe there is some more efficient way than using config-write.
If anyone get an idea, thanks.
You should have a good debug strategy. Try to minimize external influences and make a minimal example. Then try to find out where exactly the program hangs. Is it really the config stuff? Or is it those mainset_sql_* queries?
For given name "soft":
Windows: wxConfig writes to HKEY_CURRENT_USER\Software\soft.
Linux: wxConfig creates hidden .soft file in home directory.
Using wxConfig in both OS, I didn't have any performance problems. Try to investigate more, knowing where this information is saved.

C++, linux: how to limit function access to file system?

Our app is ran from SU or normal user. We have a library we have connected to our project. In that library there is a function we want to call. We have a folder called notRestricted in the directory where we run application from. We have created a new thread. We want to limit access of the thread to file system. What we want to do is simple - call that function but limit its access to write only to that folder (we prefer to let it read from anywhere app can read from).
Update:
So I see that there is no way to disable only one thread from all FS but one folder...
I read your propositions dear SO users and posted some kind of analog to this question here so in there thay gave us a link to sandbox with not a bad api, but I do not really know if it would work on anething but GentOS (but any way such script looks quite intresting in case of using Boost.Process command line to run it and than run desired ex-thread (which migrated to seprate application=)).
There isn't really any way you can prevent a single thread, because its in the same process space as you are, except for hacking methods like function hooking to detect any kind of file system access.
Perhaps you might like to rethink how you're implementing your application - having native untrusted code run as su isn't exactly a good idea. Perhaps use another process and communicate via. RPC, or use a interpreted language that you can check against at run time.
In my opinion, the best strategy would be:
Don't run this code in a different thread, but run it in a different process.
When you create this process (after the fork but before any call to execve), use chroot to change the root of the filesystem.
This will give you some good isolation... However doing so will make your code require root... Don't run the child process as root since root can trivially work around this.
Inject a replacement for open(2) that checks the arguments and returns -EACCES as appropriate.
This doesn't sound like the right thing to do. If you think about it, what you are trying to prevent is a problem well known to the computer games industry. The most common approach to deal with this problem is simply encoding or encrypting the data you don't want others to have access to, in such a way that only you know how to read/understand it.

Issuing system commands in Linux from C, C++

I know that in a DOS/Windows application, you can issue system commands from code using lines like:
system("pause");
or
system("myProgram.exe");
...from stdlib.h. Is there a similar Linux command, and if so which header file would I find it in?
Also, is this considered bad programming practice? I am considering trying to get a list of loaded kernal modules using the lsmod command. Is that a good idea or bad idea? I found some websites that seemed to view system calls (at least system("pause");) in a negative light.
system is a bad idea for several reasons:
Your program is suspended until the command finishes.
It runs the command through a shell, which means you have to worry about making sure the string you pass is safe for the shell to evaluate.
If you try to run a backgrounded command with &, it ends up being a grandchild process and gets orphaned and taken in by the init process (pid 1), and you have no way of checking its status after that.
There's no way to read the command's output back into your program.
For the first and final issues, popen is one solution, but it doesn't address the other issues. You should really use fork and exec (or posix_spawn) yourself for running any external command/program.
Not surprisingly, the command is still
system("whatever");
and the header is still stdlib.h. That header file's name means "standard library", which means it's on every standard platform that supports C.
And yes, calling system() is often a bad idea. There are usually more programmatic ways of doing things.
If you want to see how lsmod works, you can always look-up its source code and see what the major system calls are that it makes. Then use those calls yourself.
A quick Google search turns up this link, which indicates that lsmod is reading the contents of /proc/modules.
Well, lsmod does it by parsing the /proc/modules file. That would be my preferred method.
I think what you are looking for are fork and exec.

IThumbnailProvider and IInitializeWithItem

I am trying to develop an IThumbnailProvider for use in Windows 7. Since this particular thumbnail would also be dependant on some other files in the same directory, I need to use something other than IInitializeWithStream to a path to work with, this being IInitializeWithItem. (Alternatively, I could use IInitializeWithFile, but that is even more frowned upon apparently.)
No matter what I do, I cannot get it to work. I have Microsoft's FileTypeVerifier.exe tool which gives the green light on using IInitializeWithItem, but when explorer calls it, it only seems to try IInitializeWithStream, ever. (This was tested by temporarily implementing said interface, and Beep()ing away in its Initialize()) Did I forget to configure something?
In short: how do I get this to work?
Okay, I finally found out what is the matter. To quote the Building Thumbnail Providers link on the MSDN website:
There are cases where initialization with streams is not possible. In scenarios where your thumbnail provider does not implement IInitializeWithStream, it must opt out of running in the isolated process where the system indexer places it by default when there is a change to the stream. To opt out of the process isolation feature, set the following registry value.
HKEY_CLASSES_ROOT
CLSID
{66742402-F9B9-11D1-A202-0000F81FEDEE}
DisableProcessIsolation = 1
I knew I was running out of process since I read elsewhere that thumbnailproviders ALWAYS ran out of process. But since that particular snippet is on almost -all- shell extension handlers, I interpreted it to be a overly happy copy-paste job, since it was -required- to run in-process the way I understood it.
And I was wrong. I hope this will help someone else in the near future. :)