There's also a file - I always forget which - that lets you sudo a script/program without requiring the root password.
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).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
at the end.Code:yourusername ALL = NOPASSWD : ALL
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.And this won't work conveniently with pnds as their paths could change
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 would be more interested in a more convenient/abstract way to configure someting like this
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.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 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. ;-)14 minutes? did you somehow get Linux running on an old 8086 processor?
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.No, the problem is the security risk, not that it's hard to fix when something goes wrong.
I would like to.did you somehow get Linux running on an old 8086 processor?
Sure. I meant to say "the only /potential/ issue". It /does/ introduce a new point of failure.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.No, the problem is the security risk, not that it's hard to fix when something goes wrong.
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.
D'OH, I made a small script that starts the pnd I refer to in the sudoers file.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.
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.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.
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.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.
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?
How should that happen ?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?