|
Thanks,
as I suspected "stdin" and file "pipe" are what I failed to put into THE equation.
Unfortunately all these " well meaning " but superficial, distracting from subject , AKA not answering questions , commentaries about security did not help...
SOLVED
10-4
|
|
|
|
|
Hello folks, just a quick question about the Visual Studio Resource Editor:
Is it possible to use it to edit resources in a compiled executable without the source code? (Specifically the VERSION resource)
I doubt it, but I just wanted to be sure.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Yes, in the "File Open..." (Ctrl+O) dialog select file type EXE. Select the Version resource, edit it and save the file.
Mircea
|
|
|
|
|
Thanks! I never noticed that capability.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
If the exe (or dll) is signed I am guessing that would not work?
|
|
|
|
|
You still can edit it but it invalidates the signature - makes sense. Never tried it before, thanks for uncovering another detail.
Mircea
|
|
|
|
|
Voluntarily removed- violates "Posting guidelines "
modified 16-Feb-24 12:53pm.
|
|
|
|
|
|
Message Closed
modified 16-Feb-24 12:53pm.
|
|
|
|
|
process->start("sh", QStringList() << "-c" << "xterm");
It looks like you are starting a terminal session via the shell. At a guess the xterm process is running and the shell process that started it is waiting for it to finish. And your application will be waiting until both xterm and its parent shell terminate. At which time I doubt that there will be any stdout to capture.
|
|
|
|
|
Launching a gnome terminal from QT seems like a bit of a frankenstein. Surely a better option would be a terminal widget. A quick google search seems to indicate that QT does not provide a terminal widget, but others have written them, such as this one here. Failing that, you might want to pull KDE into the mix and that would get you the KDE terminal widget. Or you could use KDE Konsole as an alternative to gnome-terminal, which would keep your UI more consistent.
I'm not sure why you wan to launch a terminal to run a command and capture the output. That's what QProcess, or going down a level, popen() is for. QProcess even alows you to capture stderr, which is not as easy with popen(). The only reason you'd want to launch a terminal would be if you needed to get some user input. If you don't need that, then QProcess is probably what you want.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Message Closed
modified 16-Feb-24 12:53pm.
|
|
|
|
|
When you launch a program via QProcess, it maps the stdin/stdout/stderr to QT stream objects you can read and write to/from. That's fairly straight forward, and I think you understand that.
Now, when you launch a terminal via QProcess, the stdin/stdout/stderr of the terminal get mapped as expected. But what the terminal does is create a pseudo tty (e.g. /dev/pts/n) and uses that for the stdin/stdout/stderr for the process it's running, and displays the results in its window.
visually, something like:
QProcess <=stdin/out=> xterm
+ pty <=stdin/out=> /bin/ls In general, terminal emulators do not forward child program's I/O to its own stdin/out. There might be ways to do that, you'd have to check the manual pages for whatever terminal emulator to see if that's possible.
So this is exactly what happens if you say xterm -e /bin/ps from the command line. In this case, xterm launches, it displays the output of /bin/ps to its screen, and then closes. In the original command line window, nothing gets printed - unless there's output from xterm itself.
Hopefully that explains things a bit for you, and does not add to your confusion.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Salvatore Terress wrote: Apparently there are at least two ways to accomplish that.
All languages, C++ or anything else, for an external app has the following communication paths.
- Start Up - Command line parameters.
- Running. Exit code. Which is an int value and nothing else.
- Running. Stdio: stderr, stdin, stdout.
Using the above I have implemented the following in the past
- One computer connecting to multiple hardware devices.
- Error output collected.
- Logging collected.
- Commands controlling each device.
- Binary data sent to and from each device.
An application might provide another API. But that has nothing to do with running it from the first application. And for most standard 'OS Command line' commands it will not apply. As a specific example you can start and stop IIS using command line commands. But you are definitely not going to be accessing web sites from it using exactly the same commands (if at all using a OS command.)
Using a command line app and controlling it requires that one understand exactly what the app does. And that has nothing to do with the controller code from the calling app.
Using a OS shell is going to make the above MUCH harder. That is because the shell must then redirect all output from any commands it runs back along the stdio path (in and out.)
Getting the shell to do that has nothing to do with the calling application. One will need to figure that out by looking for command line parameter to the shell itself. Although I suspect that that it is possible to do this, at the very least I know it is difficult.
|
|
|
|
|
Message Closed
modified 16-Feb-24 12:54pm.
|
|
|
|
|
Salvatore Terress wrote: I need to have "sudo" access...
Such access has NOTHING to do with
Linux security.
Yes, it has everything to do with Linux security, as clearly explained in the man page: https://linux.die.net/man/8/sudo[^]. And although I have not tried this myself, I strongly suspect that you cannot use it in the way you are trying to do. If you want elevated/admin permissions then you most likely need to call sudo before you start the original application.
And this question has nothing to do with C/C++; please use the correct forums for your questions.
|
|
|
|
|
In today's O/S security systems, there is usually a wall between normal user processes and admin-level processes. You cannot access the streams of an admin process from a normal user process. Think about it for just 5 seconds and you'll see why this is a security risk and is now not allowed.
|
|
|
|
|
Message Closed
modified 16-Feb-24 12:54pm.
|
|
|
|
|
Message Closed
modified 16-Feb-24 12:54pm.
|
|
|
|
|
I'm sure've been over this before:
$ id
uid=1002(k5054) gid=1002(k5054) groups=1002(k5054),27(sudo),100(users)
# create a new group for bluetooth users, call it btusers
$ sudo groupadd btusers
# add user k5054 to the btusers group
$ sudo usermod -a -G btusers k5054
# edit /etc/sudoers.d/btusers to allow any user in btusers group
# to run hcitool without a password:
$ sudo visudo /etc/sudoers.d/btusers
add line %btusers ALL=(ALL) NOPASSWD:/usr/bin/hcitool
# log out and log back in again ...
$ sudo ps
[sudo] password for k5054: (CTL-D)
sudo: no password was provided
sudo: a password is required
# We're now part of the btusers group, so we don't need a password for hcitool
# id
uid=1002(k5054) gid=1002(k5054) groups=1002(k5054),27(sudo),100(users),1003(btusers)
# sudo hcitool without needing a password
$ sudo hcitool dev
Devices: If you need to be able to run other commands you can append them as a comma separated items to the sudoers file e.g.
%btusers ALL=(ALL) NOPASSWD:/usr/bin/hcitool,/usr/bin/hcidump
With knowledge comes great power. Use it wisely.
But this should really be int the linux programming forum, or maybe System Admin.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Message Closed
modified 16-Feb-24 12:54pm.
|
|
|
|
|
Salvatore Terress wrote: what am I missing ?
It makes no difference how you run that command string, it will never work. If that command succeeds then the generated shell that runs the sudo command will be elevated to (possibly root) status. It will then terminate and return to your application which runs at non-elevated level. If you want root access in your application then you have two very simple choices:
1. Do what k5054 advised and set up your account to run at higher level.
2. Call sudo in your shell before launching your application.
|
|
|
|
|
k5054 wrote: I'm sure've been over this before:
To me it is the same as the question that was posted a while ago. One of my posts in this thread has a link to my post in that previous post.
|
|
|
|
|
As we lkeep telling you, you cannot call sudo from within the program. Whether you use QProcess or system makes no difference, as neither will do what you want. You must call sudo at the actual terminal before you run your application.
|
|
|
|
|
Inappropriate post - voluntary removed
modified 11-Feb-24 20:19pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
