Page 2 of 2
Re: Sudo cannot find scripts in the user's home despite the ENV set correctly
Posted: Sun Nov 10, 2024 1:35 pm
by imschmeg
The difference between when single and double quoted strings are expanded has nothing to do with sudo. It's all bash (or whatever shell you're using).
There are many reasons sudo has obscure rules about what it does by default. Most are related to risk.
It is extremely easy for even fairly advanced linux users to make themselves more vulnerable to hacking with sudo. But, in linux land, only you can save you from you.
Re: Sudo cannot find scripts in the user's home despite the ENV set correctly
Posted: Sun Nov 10, 2024 1:56 pm
by mikech
I am very sorry fehlix. I didn't realize you needed that. I use the command line and start a bash script with "bash filename.sh" works from any directory when not not using "sudo". Didn't know there was any other way. It never occurred to me to make a launcher! I have never used a launcher and only start bash scripts for the command line.
Re: Sudo cannot find scripts in the user's home despite the ENV set correctly
Posted: Sun Nov 10, 2024 2:04 pm
by mikech
sudo PATH="$PATH" bash myscript works! It runs the script. Now I just need to find a way to automate that.
Its all about removing key strokes without compromising security for me. I once told one of my programmers when I was a project manager that I didn't care if it took 500 lines of code to remove one keystroke for the user (most new hires can't type). The programmers were not happy! 500 limes of code is much cheaper than 10,000 extra keystrokes several times a day (one per employee)!
Re: Sudo cannot find scripts in the user's home despite the ENV set correctly
Posted: Sun Nov 10, 2024 2:22 pm
by imschmeg
mikech wrote: Sun Nov 10, 2024 2:04 pm
Its all about removing key strokes without compromising security for me. I once told one of my programmers when I was a project manager that I didn't care if it took 500 lines of code to remove one keystroke for the user (most new hires can't type). The programmers were not happy! 500 limes of code is much cheaper than 10,000 extra keystrokes several times a day (one per employee)!
But adding 500 lines of code might compromise security. Because that code can contain bugs or at least make the system more vulnerable. The EULA might save the company from being sued, but not from losing customers and reputation. Add in maintenance of that extra code taking resources away from other things.
I'm a retired software engineer, so I might have been one of those not happy.
Re: Sudo cannot find scripts in the user's home despite the ENV set correctly
Posted: Sun Nov 10, 2024 2:29 pm
by fehlix
mikech wrote: Sun Nov 10, 2024 2:04 pm
sudo PATH="$PATH" bash myscript works! It runs the script. Now I just need to find a way to automate that.
Its all about removing key strokes without compromising security for me. I once told one of my programmers when I was a project manager that I didn't care if it took 500 lines of code to remove one keystroke for the user (most new hires can't type). The programmers were not happy! 500 limes of code is much cheaper than 10,000 extra keystrokes several times a day (one per employee)!
Sorry, why do you run a bash script as
"bash myscript"
instead of just
"myscript"
and with sudo as
b/c a proper bash-script which is marked as execuatable and
has the proper "shebang" -line as first line
The shebang line "#!/bin/bash" tells the kernel to run this script as bash-script.
So no need to start bash-script with running extra bash as the kernel knows already to start as bash .
Re: Sudo cannot find scripts in the user's home despite the ENV set correctly
Posted: Sun Nov 10, 2024 2:52 pm
by mikech
Felix:
OH! I did not know that. Thank you! It has "#!/bin/bash" so I must have known it when I wrote the script 5 years ago! Your question about a launcher prompted me to create one and it works perfectly. I just have to figure out how to keep the terminal open so I can see any errors. I used to know how to do it so I just need to check some of my other scripts. Thanks!
imschmeg
Good point! However we used highly skilled and qualified professional programmers who understood the need for security and we used a very robust testing system that also checked for vulnerabilities. The application lived behind a very powerful firewall with zero internet access. They just were not happy about doing all the extra work and considered it unnecessary. They were of the "the user ought to..." philosophy. Afterwards one of them thanked me because what I asked him to do was very difficult and he filed several patents for the techniques he developed. "500 lines" was a figure of speech. Nothing I asked them to do actually required 500 lines! :-)) But your right. Probably not do-able or even a good strategy in some commercial environments.
Re: Sudo cannot find scripts in the user's home despite the ENV set correctly
Posted: Mon Nov 11, 2024 5:28 am
by DukeComposed
imschmeg wrote: Sun Nov 10, 2024 2:22 pm
mikech wrote: Sun Nov 10, 2024 2:04 pm
I once told one of my programmers when I was a project manager that I didn't care if it took 500 lines of code to remove one keystroke for the user (most new hires can't type). The programmers were not happy! 500 limes of code is much cheaper than 10,000 extra keystrokes several times a day (one per employee)!
But adding 500 lines of code might compromise security. Because that code can contain bugs or at least make the system more vulnerable. The EULA might save the company from being sued, but not from losing customers and reputation. Add in maintenance of that extra code taking resources away from other things.
Write 500 lines to save one keystroke. Pat self on the back for the productivity boost. Realize you now have to pay your engineers to write a specification for those 500 lines, unit tests, and documentation. Update training everywhere since it changes end user workflows and send multiple announcements they won't read, with a timeline they won't remember. Hold multiple meetings to solicit usability feedback. Check the new code into source control. Tag it for regular security review at six month intervals and factor in the additional regression testing into your CI/CD test matrix. Notify your on-call rotation about the update and provide best practices. Hold multiple meetings to calculate the lifetime of the project and when to assign it to a sustained engineering resource.
All over one keystroke. Choose carefully.