Make executable bash script run with sudo privileges?

[bingbong6]

Well nonetheless. Thanks for all of your input thus far. My really important data is stored off system on a flash drive and an external hdd. But I just don't want the inconvenience of setting up my desktop again. Maybe use the opportunity to distro hop haha.

BTW timeshift is just a nice gui with scheduling built in that just uses rsync at its core.

[TheFu]

BTW timeshift is just a nice gui with scheduling built in that just uses rsync at its core.

rsync has some failures as a backup tool. For example, when using the hardlinking capabilities to provide versioned backups, it cannot track changes to the owner, group, permissions or ACLs.

Most backup tools on Linux have some part of rsync used, but the better tools handle the file metadata in their versioning too.

I get that lots of people want a GUI for backups. Most of my systems don't have a GUI, so that would be useless to me. Also, running a GUI under sudo is asking for trouble. It is a good way to cause permission issues with a userid.

Tip: Whenever using sudo with a GUI programs - first - don't. But if you must, always use sudo -H so the HOME directory gets modified too.

[CatKiller]

@CatKiller

I thought you guys said to change it to the full path so it couldn't be changed and exploited? Or did you mean changing it so that I didn't need sudo so that someone couldn't just swap out the command following sudo?

I mean that in your script you'd simply have

/usr/sbin/grub-reboot 2

[CatKiller]

so both are deprecated and we should be using systemctl with specific options, it seems. That would complicate your sudoers file, but not mine. Allowing systemctl to be run with any available options could be really bad. Terrible. Lots of power in that command to which I wouldn't want just any casual admin to have access.

Actually, systemd turns it into a one-liner:

pkexec systemctl reboot --boot-loader-entry=windows

and you can easily configure polkit to allow the user to do only that action without a password. It is much less fragile than sudoers.

[CatKiller]

My really important data is stored off system on a flash drive and an external hdd. But I just don't want the inconvenience of setting up my desktop again.

All your user settings are in /home (that's what it's for) so copying those back into a fresh install will make everything how it was. There are also commands for listing every package that you've installed so that you can automate reinstalling them in a fresh install.

[CatKiller]

For completeness:

Not sure what entries nor what menu you're referring to, but I did find several guides. I will try that instead.

Gnome used to default to a standard drop-down menu for launching applications, and many desktop environments still do.

Desktop files are agnostic ways of defining the properties of something that you want to launch. The launcher menu, any docks you use, the panel, the context menu, and launchers on the desktop are all controlled the same way, and it works for all desktop environments. Because of that abstraction of listing the attributes in a text file it's much more flexible and prevents you from, say, deleting important files when you just want to change how it runs.

[bingbong6]

@catkiller

Is there anyway to just restorey /bin file only? I have the backup. Others have mentioned fire up a live disk, go into terminal as root (which I will avoid in the future bc this is what got me in this pickle), then copy the /bin file from my backup to my system root. Any reason this wouldn't work or at least wouldn't be worth a shot?

[CatKiller]

It's definitely worth a shot. If you simply deleted that directory, and your backup contains that, then that's what your backup is for.

[bingbong6]

I know some would disagree, but I don't mind when stuff like this happens. I have external backups of important data and my home desktop is just for play anyway. I always learn something when I break stuff. In this case, I learned the hard way what everyone warns about avoiding logging in and doing stuff as root in the terminal.

I'm not a sys admin or any computer related career. I'm a Mechanical Engineer and that's how I've always learned; tear stuff apart to learn how it works and then put it back together. Probably not always the right approach with computers, but that's more or less what I was trying to do with executable. Seemed like something worth exploring to learn a thing or two.

I think for now, I will just continue to use my script via terminal and enter a password. I mentioned that I was using dconf to force a prompt when double clicking an executable file, and you mentioned that I could just use a flag terminal=true to achieve this. How do I set a terminal=true flag on my executable?

I think I'll avoid the nopasswd method Until I learn more about good security practices and how to edit permissions etc. Think I got a bit ahead of myself. I appreciate your help and TheFo's help.

[CatKiller]

I always learn something when I break stuff.

That is a perfectly healthy attitude. I broke a bunch of stuff in the beginning, too.

I think for now, I will just continue to use my script via terminal and enter a password. I mentioned that I was using dconf to force a prompt when double clicking an executable file, and you mentioned that I could just use a flag terminal=true to achieve this. How do I set a terminal=true flag on my executable?

It's not for the script, it's for the launcher that launches the script. As I mentioned earlier, that abstraction is very handy. You can put your script wherever makes sense for that, and have your launcher wherever you need to launch it from.

There's a post here, in a different context, that describes a bit about how the desktop files work. I think there were links to more information, too. You can drag and drop into a text editor from the menu, or /usr/share/applications, if you want to see how it all works for other applications.

You can either use sudo and launch your script in a terminal, or use pkexec and launch your script without a terminal, whichever you prefer.