I have a Qt 4 GUI where I need to have a option in a drop-down menu that allows the user to choose to restart the computer. I realize this might seem redunant with the ability to restart the computer in other ways, but the choice needs to stay there. I've tried using system() to call the following:
a suid-root shell script
a non-suid shell script
a suid-root binary program
and all of them just cause reboot: must be superuser to be printed. Using system() to call reboot directly does the same thing. I'm not especially attached to using system() to do this, but it seemed like the most direct choice.
How can I reboot the system from the GUI?
The reboot function is described in the Linux Programmer's Manual. Under glibc, you can pass the RB_AUTOBOOT macro constant to perform the reboot.
Note that if reboot is not preceded by a call to sync, data may be lost.
Using glibc in Linux:
#include <unistd.h>
#include <sys/reboot.h>
sync();
reboot(RB_AUTOBOOT);
In Linux:
#define LINUX_REBOOT_CMD_POWER_OFF 0x4321fedc
sync();
reboot(LINUX_REBOOT_CMD_POWER_OFF);
Have you tried running a shell script, using gksudo? Something like
gksudo shutdown -r
With any luck, that should pull up a modal dialogue to get user credentials.
suid-ing shell scripts is just dangerous as already mentioned (which is why that didn't work).
I suspect that suid-ing the binary doesn't work because system spawns its subprocess with the user's actual uid and not the suid one, again for security reasons (it would let you substitute any binary for the one being called and run it as root).
You could put a copy of reboot in a location protected such that only users you want have permission to can execute it, and then suid-root THAT.
Alternately give them sudoer privilege to execute JUST the command you care about and system out to something like "ksh -c 'sudo reboot'"
This should do it on almost any linux system.
#include <unistd.h>
#include <sys/reboot.h>
int main () {
sync();
setuid(0);
reboot(RB_AUTOBOOT);
return(0);
}
Then just compile with gcc reboot.c -o reboot and do chmod a+s reboot on the binary. Then call reboot as any user and the system should reboot smoothly. The way you do this through your GUI varies, as in if your Desktop Environment was KDE for example, it's quite different than doing the same thing under Fluxbox.
In binary try to call
setuid (0);
before system() call.
how would you reboot the system from the command line on your system?
basically do
system( <however you wouuld do it from the command line> );
Related
I am using gdbserver to debug a remote process. I am able to attach gdbserver to the process after it has launched and is waiting for input.
However, I want to attach gdbserver to the process while it is being launched. The process is launched via a shell script and I cannot change how this process is being launched i.e. I cannot modify the shell script to launch the process via a call to gdbserver.
How do I attach gdbserver to this process as soon as it launches?
Edit: I am able to create a wait loop at the start of main(). For example a loop which waits till it finds a file at a predetermined location :
#include <unistd.h>
int main() {
while( access("/home/username/CONTINUE", F_OK) == -1)
sleep(1);
/*
...all the rest of main()
*/
return 0;
}
We can attach gdbserver while the process is busy with this loop, set breakpoints as required and say touch /home/username/CONTINUE to exit the loop. But this requires us to be able to access the source code, compile the binary and place it on the target machine. I am looking for a better, easier way than this.
But this requires us to be able to access the source code1, compile the binary and place it on the target machine. I am looking for a better, easier way than this.
It looks like you are working on a linux / unix like remote operating system.
If you have admin access to the remote system, the simplest way I could think of is to rename the original executable, and replace that with a shell script named like the original executable, that starts the now renamed under control of gdbserver.
Something like (assumed executable /usr/bin/foo) at the target machine:
root:# cd /usr/bin
root:# mv foo foo_
root:# echo "#!/bin/sh\ngdbserver /dev/com1 foo_ foo.txt" > foo
root:# chmod a+x foo
As it says in the gdbserver man(1) page:
This tells gdbserver to debug foo_ with an argument of foo.txt, and
to communicate with GDB via /dev/com1. gdbserver now waits patiently
for the host GDB to communicate with it.
Another way I could think of without modifying the original process at all, could be a little program that monitors changes in the /dev/proc directory(ies), and attaches gdbserver at such event with the associated pid.
Though it's kind of luck then, if gdbserver is attached, before that process already schedules to main().
1You should have acces to the source code anyways for reasonable debugging with gdb. Though there are cases where you can just get with the (dis-)assembly code as well.
I've got a program called pgm1 which create a new process using fork.
Then in this process, I launch a new program (pgm2) using the following command:
execv( exec_path_name, argv ).
But the thing is that with this method I've got both output in the same terminal.
I've been searching for a while ans the only solution i found was this one:
Open a new terminal with a system call
Attach my pgm2 to the new terminal using this soft http://blog.nelhage.com/2011/01/reptyr-attach-a-running-process-to-a-new-terminal/comment-page-1/#comment-27264
So my question is really simple, is there a more simple way to do that ?
Thanks in advance !
PS: Distro - Ubuntu 11.10 32bit
I can think of two possible solutions:
Do The Right Thing(TM) and send your output to a file: Each process can use a different file, providing both clear separation of the output and better record-keeping. As a bonus, you are also bound to see a performance improvement - terminal output is computationally expensive, even nowadays...
Execute a terminal emulator with the proper arguments: Most terminal emulators provide a way to execute a specific program in place of the shell. For example xterm:
$ xterm top
This will launch top in an xterm instance, without a shell. Quiting top also terminates the xterm window.
If your terminal emulator of choice supports this, you can use it simply by modifying the arguments passed to execv(). Of course, in this case you will be actually executing the terminal emulator instead of your program, which will then call your own process.
Keep in mind that, depending on the terminal emulator, any open file descriptors may not be passed correctly to your program - the terminal will at least mangle the standard file descriptors.
In C/C++ how can my programs determine if there is a desktop (system or remote) or not?
My project has three separate programs running (now) in separate gnome-terminals. It is launched by the last line of .profile, so it starts whether I am at the system desktop (gnome) or remotely connecting by VPN/telnet or VPN/remote-desktop. My machine is 250 miles away at a test site, so I frequently login remotely to make changes and have to restart the program.
I'd like my program to be able to detect that it is launched from a desktop environment or from a telnet session. Preferably, I want them to continue running after the remote connection is broken.
Obviously, I need to make my programs into daemons so they will persist after I close the connection. But if I start them in a terminal on a desktop environment, where I can actually have three terminals open, I'd like to watch their progress messages. And if I disconnect the remote desktop, I'd like the daemons to detect this and turn off printing (to the now killed terms) but keep on running in normal (silent) daemon mode. Best of all, the programs could recheck for a desktop occasionally and resume printing by opening new terminals.
Is this possible? Any coding suggestions?
Thanks in advance.
You can use the isatty function. Detect if stdin is a terminal or pipe?
#include <stdio.h>
#include <io.h>
//...
if (isatty(fileno(stdin)))
printf( "stdin is a terminaln" );
else
printf( "stdin is a file or a pipen");
You can find more information at http://www.chemie.fu-berlin.de/chemnet/use/info/libc/libc_12.html
Some more code: http://pastebin.com/S3Lr9tik
The traditional solution for this problem is an option in the command
line. Such programs will typically demonize themselves unless given a
special debug option telling them not to.
Another solution would be to use a shell script to start the program as
a demon, via the nohup command (and redirecting standard input and
output to /dev/null).
As for determining whether your managing terminal is local or not, it
could be difficult; both X and telnet use virtual terminals, so if
you're running under X, you may not be able to distinguish between a
telnet session and a local xterm window. Still, it might be worth
trying... Under Linux, /proc/<procid>/fd/0 is a symbolic link to the
device connected to standard in (fd 0): using something like readlink,
you should be able to determine the actual name. Or fstat will give
you the major and minor numbers of the device. Given these, you might
be able to determine which is which. If your local terminal is not
under X, but a real terminal, it will definitely have a different minor
number than a pseudo-terminal. For xterms, it's possible that the minor
numbers of the pseudo-terminals fall in different ranges, or even that
there are distinct sets of pseudo-terminals for remote links and for X;
you'll probably have to experiment some, and there might be no working
solution. (For starters, to tty at each terminal, and see what it
says. I don't have local access to a Linux machine to check, but I seem
to remember that on Solaris, X terminals had names like /dev/ttyxx; my
remote terminals on Linux here are /dev/pts/xx. (Where xx is a
number in each case.)
I am designing an C++ app that, among other things, executes a few scripts every now and then. The app should be efficient and preferably platform independent.
The issue is, however: is there a reason one shouldn't use system() call for launching scripts and use, for example, POSIX facilities instead? The discussion on the matter that I've seen so far usually boils down to:
system() is less flexible. (Fine with me)
It offers no control of the command being executed. (Fine with me, I just need a return value from the script)
It is not quite platform independent. (Now, this would be a concern. I would really love to see an example where it behaves differently on different platforms)
It is a security concern. (Again, this would be an issue. Can someone provide an example of a potential security problem with system()? )
Any other issues?
3) It is not quite platform independent (Now, this would be a concern. I would really love to see an example where it behaves differently on different platforms)
Well, for instance system("ls") would probably fail in Windows, since there is no ls command.
4) It is a security concern. (Again, this would be an issue. Can someone provide an example of a potential security problem with system() ? )
If the argument passed to system comes from user input, and not properly validated, it can be used to execute unwanted things with the privilege levels of the original executer. If its static content, its quite easy to find that within an executable image and modify it to do nasty things as well.
(3) If you just want a counterexample, for example grep behaves differently on Solaris vs Linux vs whatever.
(4) Your program's privileges are inherited by its spawned programs. If your application ever runs as a privileged user, all someone has to do is put their own program with the name of the thing you shell out too, and then can execute arbitrary code (this implies you should never run a program that uses system as root or setuid root).
(5) It will probably be saner to maintain in the long run to use the posix facilities because you won't have to rely on a specific set of external scripts or binaries already existing wherever your program runs.
I maintain a system that consists of several separate executables. In this case I have control over the permissions, names, calling conventions, security over all supported platforms. In this case, system() works just fine. The applications communicate through a RDBMS.
Again, as others have noted "The Devil's in the details".
Regarding security concerns, a classical example about (4) is the following scenario: imagine the user is prompted to give some directory name to be backed up into a std::string dirname; then you'll compute some backup directory name into a std::string backup and do
system((std::string{"cp -a "} + dirname + " " + backup).c_str())
Now think what happens if a malicious user enter foo bar; rm -rf $HOME; ls as the dirname and backup is /vol/backup_2015_fev/. The system command would execute
cp -a foo bar; rm -rf $HOME; ls /vol/backup_2015_fev/
which is not what you expected (all the user's $HOME would be deleted!). This is an example of code injection, and when using system you should ensure that it never happens (e.g. by sanitizing and/or escaping every user input related string)
Also, the PATH might not be what you believe it is (e.g. starting with /tmp/ and a malicious user having done ln -s /bin/rm /tmp/cp before your system runs).
I used the system() call in my CGI C++ app under windows and Linux too.
One problem I had was when using system() was not having the proper access rights to execute my skript with the web user.
I did not have that problem any more when using the CreateProcess() method.
Whatever command you want to execute just store that in a file c.txt. Pass that file to the execl() like as done below.
fd = open("c.txt", O_CREAT | O_RDWR, 00777);
write(fd,arr,sizeof(arr));
if(fork() == 0)
{
execl("/bin/sh", "sh", "-c","sh c.txt", (char *) 0);
}
I need to run a linux command such as "df" from my linux daemon to know free space,used space, total size of the parition and other info. I have options like calling system,exec,popen etc..
But as this each command spawn a new process , is this not possible to run the commands in the same process from which it is invoked?
And at the same time as I need to run this command from a linux daemon, as my daemon should not hold any terminal. Will it effect my daemon behavior?
Or is their any C or C++ standard API for getting the mounted paritions information
There is no standard API, as this is an OS-specific concept.
However,
You can parse /proc/mounts (or /etc/mtab) with (non-portable) getmntent/getmntent_r helper functions.
Using information about mounted filesystems, you can get its statistics with statfs.
You may find it useful to explore the i3status program source code: http://code.stapelberg.de/git/i3status/tree/src/print_disk_info.c
To answer your other questions:
But as this each command spawn a new process , is this not possible to run the commands in the same process from which it is invoked?
No; entire 'commands' are self-contained programs that must run in their own process.
Depending upon how often you wish to execute your programs, fork();exec() is not so bad. There's no hard limits beyond which it would be better to gather data yourself vs executing a helper program. Once a minute, you're probably fine executing the commands. Once a second, you're probably better off gathering the data yourself. I'm not sure where the dividing line is.
And at the same time as I need to run this command from a linux daemon, as my daemon should not hold any terminal. Will it effect my daemon behavior?
If the command calls setsid(2), then open(2) on a terminal without including O_NOCTTY, that terminal might become the controlling terminal for that process. But that wouldn't influence your program, because your program already disowned the terminal when becoming a daemon, and as the child process is a session leader, it cannot change your process's controlling terminal.