|
Member 14968771 wrote: The -S (stdin) option causes sudo to read the password from the standard input instead of the terminal device.
Which is what my post it about.
You run the command in code.
Then you code that code so you can control "standard input" (ie "stdin") which is exactly what I suggested via my google search.
By steps.
1. Write code to run the command
2. Figure out how to use the 'stdin' input in the code. That allows your code to pass content to the 'stdin' of the command.
3. You then pass input in via that code to the command.
|
|
|
|
|
It would be much easier to call sudo from the terminal before you try to run whatever code itb is that you are trying to run that requires privileged access. My limited testing does not seem to allow this to be run from inside a program.
|
|
|
|
|
An easier option might be to configure sudo to allow the user of your program to call it without a password. The sudoers file is the place to do this. Obviously there may be security implications with this, but that is up to you to decide.
Another alternative is to set the set-user-id bit on your executable so that it automatically runs as root (using chmod and chown). Again, this has security implications to think about.
|
|
|
|
|
Rather than system() take a look at popen() popen(3): pipe stream to/from process - Linux man page
But before you do that, you should stop and think about whatever it is you think you need to sudo. As a general rule user level programs should not need to elevate privilege to perform work. That's a security hole waiting to be exploited. If you need to create a device file, load a kernel module or change permissions on a device file, that should be handled by the OS at boot time or device initialization time (eg a USB device being plugged in). Using sudo is almost certainly the Wrong Thing, and should only be considered when all other options have been exhausted.
Keep Calm and Carry On
|
|
|
|
|
Message Closed
modified 4-May-23 8:39am.
|
|
|
|
|
The expression "echo ""q"" | sudo ... " doesn't do what I think you think it does. But it all works out anyway. This time. Successive string constants, with only intervening white space get concatenated together so
printf("Hello"
" World!\n");prints Hello World!. See. You learned something from "sidechatter"!
Member 14968771 wrote: I need to be honest - I am getting discouraged by posters "making small talk" posts such as
...make sure you have a backup...
...it is a security issue...
To my mind, there's been very little in your previous posts that suggest you have any idea what issues you might be unleashing with your blind man with a sledgehammer approach. There's no sense that you understand what the possible consequences of your choices are. Given that, it would be remiss of us not to point out the possible pitfalls of your "solutions" ... many of which, I at least, find dubious. And most of us have "Been there, done that" in terms of making unwise or uninformed choices, and had to rebuild, repair, and recover. If we're lucky, damage to customer systems, and our reputations, has been minimal. But we learn. We grow. We pass on our insights (and war stories) to others in hopes that they will learn, remember and be proactive in areas like security before it affects them or their customer's in negative ways. It's all about an ounce of prevention being worth a pound of cure. If we can guide others away from dangers, I think we should, rather then letting the foolhardy walk unprepared into the lions den.
For example, I don't think that creating /dev/rfcomm0 as a soft link to /dev/ttyUSB0 is going to achieve what you expect. Have you tested this approach and got the results you want? Looking at this post https://unix.stackexchange.com/a/410128 regarding a missing /dev/rfcomm0, it seems highly unlikely that creating a link between what seems to be a USB serial device and what I can only assume is supposed to be a bluetooth device binding is going to work. They're completely different objects. It seems like you're trying to create a link between, say /dev/sda and /dev/console, and expect GPU I/O operations to somehow be magically interpreted to save video to the disk.
But maybe you have already done some testing and know that works. I don't know. I can only wish you luck.
Keep Calm and Carry On
|
|
|
|
|
Member 14968771 wrote: I am trying to resolve an issues , not to having to listen to such well meaning but in my view superficial commentaries...
Then pay someone for the answer maybe?
Forums, free forums, depend on posters posting whatever they want.
|
|
|
|
|
Member 14968771 wrote: I am getting discouraged by posters "making small talk"
And we are largely doing this because, as usual, it is far from clear what actual problem you are trying to solve. The original question is fine as it stands, but with more detail we may be able to offer alternative answers. There may be a perfectly reasonable answer to your real problem, but we cannot giuess what that is. You really need to stop attacking everyone for not providing what you determine is the right answer, and stop and think about the quality of the questions you post here.
|
|
|
|
|
The quality of the answers you get is directly dictated by the quality of the questions you ask.
|
|
|
|
|
Member 14968771 wrote: therefore I am removing it.
It was bad idea to delete the original question. 
Now no one reading this discussion won't understand its subject... 
|
|
|
|
|
You need to understand that he really doesn't care for advice.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
su with no arguments runs a shell as root. The password prompt is looking for root's password, not the current user. Similarly su -u bob will prompt for the password for bob. If the current process has root permissions, then no password prompt is
sudo, on the other hand prompts for the current users password. As you probably know, sudo then checks /etc/sudoers to confirm that the current user has permission to run sudo.
So sudo su prompts for the current users password. If that succeeds, then the user is given root permissions and the command su is executed. As the invoking process to su has root permissions, no password prompt is issued, and su starts a root level shell. If you look at your process table, you will see that you have 3 processes now running, sudo, su, bash. Compare that to just sudo bash, or sudo -s, which will only have 2 processes running, namely su and bash.
Keep Calm and Carry On
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Member 14968771 wrote: Can I ask you to "translate" this to English for me ?
QP->start("/bin/sh", QStringList() << "-c" << command);
Sure: call operator<< on the results of calling some unknown function QStringList() and (char *)"-c" and then call operator<< on the results of that with some unknown object command. Then pass that ojbect and (char *)"/bin/bash" to method start on some unknown object QP. What any of this actually does in not known in the context of what you've presented here. I'm guessing it pulls the tail on a elephant at the Bronx Zoo. Its as valid a guess as anything else.
Assuming this goes back to your question about creating a link between /dev/ttyUSB0 and something that looks might be a bluetooth device file (which you've now helpfully removed, so I can't refer to it .. nice), Are you sure that's what you want to do? This would suggest that you have a serial USB dongle (i.e. an RS232 to USB converter) to which you've attached a serial BlueTooth receiver. I don't know if any such beast actually exists. I suspect not, so you're probably going in the wrong direction here.
But a quick perusal of the docs for QProcess, which is what I assume that QP is, doesn't suggest that QP launches a terminal, so is that part of what command does? Perhaps you'd be better off looking into how to use sudo to let a user launch a given command without having to enter a password? https://askubuntu.com/a/159009 Alternatively, you could change the ownership of the executable to a user with sufficient access to perform whatever task it is you're trying to do, and then set the suid bits on the executable so the executable runs as that user. You man need to call seteuid() and setegid() as well.
Keep Calm and Carry On
|
|
|
|
|
k5054 wrote:
I'm guessing it pulls the tail on a elephant at the Bronx Zoo.
And you can judge the success by the odor and the Bronx cheer that results!
CQ de W5ALT
Walt Fair, Jr.PhD P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Message Closed
modified 5-May-23 10:29am.
|
|
|
|
|
Assuming that QP is a pointer to a QProcess Class | Qt Core 6.5.0[^] object then:
1. QStringList() << "-c" << command creates an array of strings which will form the second parameter of the QP->start call.
2. QP->start("/bin/sh", ... will create a shell process which reads the strings passed in via QStringList above, and executes the command string in the shell.
3. What happens next is not clear since it will depend on the actual command string, and how the start function treats the created process. The documentation should clarify.
|
|
|
|
|
I don't think it does. The QProcess::start method just starts the program: in this case a shell. The started program will process the information passed in via the QStringList, and then (probably) terminate. I don't use QT so I have no way of testing this. But I do not think you can call sudo or su in this way as the elevated process will be the started shell, and not your application. As I suggested in reply to your other question, you need to get the elevated privilege before starting your application.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
