Request: Easy way to "elevate" programs


thatgui

Advanced Member
Joined
Apr 2, 2009
Messages
3,048
Don't know if its the proper subsection, but anyaway:

Would it be possible to have an (preferably) easy way to "elevate" programs - either binaries installed by a package manager or "pnds", so I don't need to hack in my password everytime I want to start it ?
 
you can make a terminal superuser by using sudo -i (so you only need to type the password once as long as the terminal is open).

You can also visudo as root and add the line


yourusername ALL = NOPASSWD : ALL

at the end.
 
There's also a file - I always forget which - that lets you sudo a script/program without requiring the root password. I remember adding my first USB Mass Storage script in when I was fiddling with that for the ConfigButton plugin
 
There's also a file - I always forget which - that lets you sudo a script/program without requiring the root password.

sudoers file? 


if so that is the file that the visudo command edits.
 
Last edited by a moderator:
you can make a terminal superuser by using sudo -i (so you only need to type the password once as long as the terminal is open).

You can also visudo as root and add the line

Code:
yourusername ALL = NOPASSWD : ALL
at the end.
I know about these, I would be more interested in a more convenient/abstract way to configure someting like this. And this won't work conveniently with pnds as their paths could change (so the pnd deamon would need to take care of keeping things up to date).
 
And this won't work conveniently with pnds as their paths could change
It should always be /mnt/utmp/<pnd>/whatever. No matter where you put the PND it'll always be the same, unless you change the name of the executable, in which case it'd need a change regardless of whether it's a PND or not. But once the PND is ready for "production" it shouldn't change and should have no problem being added to the sudoers file if that is what you want.
I would be more interested in a more convenient/abstract way to configure someting like this
Part of the security of Linux stems from the permission system and the fact that you pretty much need to be explicit when working around it. You could write a script which modifies the sudoers file automatically but anything that modifies security automatically is a risk that you should think long and hard about before implementing.
 
I'd be very wary of programatically altering sudoers. Screw it up and you break sudo. Not remembering the root password at the same time (if you've even got one) and boom, box locked. These days with bootable live CDs I guess you could boot one of those, mount your partitions and fix sudoers, but that's a good afternoon's work.
 
I'd be very wary of programatically altering sudoers. Screw it up and you break sudo. Not remembering the root password at the same time (if you've even got one) and boom, box locked. These days with bootable live CDs I guess you could boot one of those, mount your partitions and fix sudoers, but that's a good afternoon's work.
5 minutes to boot, 1 minute to mount the partition containing the botched sudoers file, 3 minutes to open and change that file, 5 minutes to reboot. Results in 14 minutes of work.If you need to search for a live CD add another 5 minutes, if you need to download and burn it first add 10 minutes and a variable amount depending on your internet connection.

No, the problem is the security risk, not that it's hard to fix when something goes wrong.
 
14 minutes? did you somehow get Linux running on an old 8086 processor?
 
14 minutes? did you somehow get Linux running on an old 8086 processor?
I was being very generous with the amounts of time because for the sake of the argument it doesn't matter that much, it's less than "a good afternoon's work" anyway. ;-)
 
By the time I get home, cook dinner, clean up, complete the daily ritual that keep the evil forces at bay, and feed the cats I have exactly 13 minutes of "afternoon". There is no way I can have the time to fix a broken sudoers file.
 
No, the problem is the security risk, not that it's hard to fix when something goes wrong.
The security of an automated solution depends on the security of your code. I see setting your sudoers to NOPASSWD: All for your account more of a guaranteed security issue personally.
That said, I've set specific commands to NOPASSWD in my sudoers so my scripts can do stuff like eject the CD drive. I've not yet found a reason to find a way to do it dynamically, and don't quite understand why that's not a solution for everyone.
 
No, the problem is the security risk, not that it's hard to fix when something goes wrong.
The security of an automated solution depends on the security of your code. I see setting your sudoers to NOPASSWD: All for your account more of a guaranteed security issue personally.
That said, I've set specific commands to NOPASSWD in my sudoers so my scripts can do stuff like eject the CD drive. I've not yet found a reason to find a way to do it dynamically, and don't quite understand why that's not a solution for everyone.
Sure. I meant to say "the only /potential/ issue". It /does/ introduce a new point of failure.
 
It should always be /mnt/utmp/<pnd>/whatever. No matter where you put the PND it'll always be the same, unless you change the name of the executable, in which case it'd need a change regardless of whether it's a PND or not. But once the PND is ready for "production" it shouldn't change and should have no problem being added to the sudoers file if that is what you want.
D'OH, I made a small script that starts the pnd I refer to in the sudoers file.
Part of the security of Linux stems from the permission system and the fact that you pretty much need to be explicit when working around it. You could write a script which modifies the sudoers file automatically but anything that modifies security automatically is a risk that you should think long and hard about before implementing.
Of course it is always about finding the right balance between a convenient user experience and keeping security tight, but I can't see an issue here currently:I'm asking for a small utility that gives you the option to include certain programs into the sudoers file (or remove them again later on, if you don't want them in there anymore), as every other application that alters system internas, it should be secured by the usual measurements.

But where is the difference ? With elevated rights an application can do as much harm as it likes (or not), regardles of wether I need to enter a password everytime before I start it or only once to "elevate it".

The security of an automated solution depends on the security of your code. I see setting your sudoers to NOPASSWD: All for your account more of a guaranteed security issue personally.

That said, I've set specific commands to NOPASSWD in my sudoers so my scripts can do stuff like eject the CD drive. I've not yet found a reason to find a way to do it dynamically, and don't quite understand why that's not a solution for everyone.
So what you are basically saying is that a tried and tested solution to alter a file is more prone to error than someone editing the file manually? With making a not so brave assumption that around 50% of the current Pandora/future Pyra users won't have much experience in that field, earning money as a software developer for almost 12 years now, and at least 20 years beeing rather akin to computers, I feel otherwise.
 
Last edited by a moderator:
So what you are basically saying is that a tried and tested solution to alter a file is more prone to error than someone editing the file manually?
Not error, maliciousness. If you're manually putting the line in, even if you make a mistake, at least you know exactly what is being put in there. If you trust a program a hundred times to do the right thing and then one time someone manages to slip in a "rm -r /" without you knowing it you're boned.
 
So what you are basically saying is that a tried and tested solution to alter a file is more prone to error than someone editing the file manually?
Not error, maliciousness. If you're manually putting the line in, even if you make a mistake, at least you know exactly what is being put in there. If you trust a program a hundred times to do the right thing and then one time someone manages to slip in a "rm -r /" without you knowing it you're boned.
How should that happen ?
 
Compromised repo account? Updated plugin? Remote resource injection? MITM? Exploit in preview image handling?
 
Back
Top