<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 5, 2020 at 7:45 PM Greg Oliver <<a href="mailto:oliver.greg@gmail.com">oliver.greg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">On Thu, Mar 5, 2020 at 9:40 PM Allen Edwards <<a href="mailto:allen.p.edwards@gmail.com" target="_blank">allen.p.edwards@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 5, 2020 at 7:07 PM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 5 Mar 2020 09:40:12 -0800, you wrote:<br>
>On Thu, Mar 5, 2020 at 8:50 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>><br>
>> On Thu, 5 Mar 2020 07:19:49 -0800, you wrote:<br>
>> >Thank you for this.  I have modified my killgui.sh file to add sudo<br>
>> ><br>
>> ><br>
>> >*#!/bin/bash         while [  true  ]; do                sudo systemctl<br>
>> >isolate multi-user.target                if [ $? -eq 0 ]; then<br>
>> >       sudo systemctl isolate graphical.target                     exit 0<br>
>> >              fi                sleep 1         done*<br>
>> ><br>
>> >I created a test file that will only run with root permissions and put it<br>
>> >in /etc/sudoers.d/ and changed the permissions and it runs.<br>
>> >*chown root:mythtv*<br>
>> >*chmod ug=rx,o=*<br>
>> ><br>
>> >My plan is to wait until I have a real lockup and run the file manually.<br>
>> >When that test is successful, I will modify* /home/dad/.mythtv/lircrc*<br>
>> like<br>
>> >this<br>
>> ><br>
>> >*config = /etc/sudoers.d/killgui.sh &*<br>
>> ><br>
>> >Hopefully I have this all correct.  Please let me know if I screwed<br>
>> >anything up :-)<br>
>> ><br>
>> >Allen<br>
>> Looks like you have things a bit back to front there.  Either the<br>
>> killgui.sh file needs to be run using sudo (and therefore needs an<br>
>> sudoers.d entry to allow it to be run without a password), or<br>
>> killgui.sh needs to call another file using sudo that can run<br>
>> systemctl.  Killgui.sh can not directly run things using sudo.  And<br>
>> the sudoers.d files are not executables - they are sudoer config files<br>
>> that provide sudo permissions to the executables.<br>
>> So one way to do it would be to remove the sudo commands in killgui.sh<br>
>> and run the whole of killgui.sh using sudo.  Then it can run systemctl<br>
>> directly without sudo.<br>
>> Then you need to work out what user things will be run from when you<br>
>> run them from a button in lirc, and set up the sudoers.d file for<br>
>> killgui to allow it to be run from that user without a password.<br>
>> Running the whoami command from the killgui script and storing the<br>
>> output of it to a file in /tmp should show the username.  When that<br>
>> logging is working, run it from a lirc button.<br>
>> So if killgui.sh is in /usr/local/bin and it will be run from user<br>
>> lirc, then you would need a /etc/sudoers.d/killgui file that contains<br>
>> something like this:<br>
>> lirc ALL=NOPASSWD:/usr/local/bin/killgui.sh<br>
>> The /etc/sudoers.d/killgui file must be chown root:root and chmod<br>
>> u=r,g=r or it will be ignored.<br>
>> The killgui.sh file needs to be run using sudo, so the command in the<br>
>> lirc config file would be something like this:<br>
>> config = sudo /usr/local/bin/killgui.sh &<br>
>> To do it the other way around, you would replace the sudo systemctl<br>
>> commands in killgui.sh with calls to a helper script.  So<br>
>> /usr/local/bin/killgui-helper.sh might look like this:<br>
>> #!/bin/bash<br>
>> if [ "$1" == "" ]; then<br>
>>     exit 1<br>
>> elif [ "$1" == "graphical" || [ "$1" == "multi-user" ]; then<br>
>>     # Execute systemctl isolate command on the specified target.<br>
>>     systemctl isolate $1.target<br>
>> else<br>
>>     exit 2<br>
>> fi<br>
>> and in killgui.sh you would replace "sudo systemctl isolate<br>
>> graphical.target" with:<br>
>>   sudo killgui-helper.sh graphical<br>
>> and you would have /etc/sudoers.d/killgui-helper with this:<br>
>> lirc ALL=NOPASSWD:/usr/local/bin/killgui-helper.sh<br>
>> and the lirc config would be:<br>
>> config = /usr/local/bin/killgui.sh &<br>
>> The second way is more complicated (it takes two scripts), but easier<br>
>> to use as you can run killgui.sh directly from any user specified in<br>
>> the sudoers.d file without using sudo.  So if you want to be able to<br>
>> ssh into the MythTV box as user "dad", user "mythtv" or any user in<br>
>> the "mythtv" group and run killgui.sh manually as well as via a lirc<br>
>> button, your /etc/sudoers.d/killgui-helper file would look like this:<br>
>> lirc,dad,mythtv,%mythtv ALL=NOPASSWD:/usr/local/bin/killgui-helper.sh<br>
>I see now that my test was not good as I had already entered my password in<br>
>previous testing so the system did not ask me again when I did the test and<br>
>thus I thought I had it nailed. I just tried again and password was<br>
>requested so obviously I had it screwed up as feared and as you have<br>
>pointed out.<br>
>There obviously is a lot to learn on this sudoers thing that I do not<br>
>understand. I will try the things you have suggested and see if I can<br>
>figure it out.<br>
>I am not concerned about being able to run the file from multiple users as<br>
>I can just have multiple copies of the file.<br>
>One question just to clarify. If my file is called  killgui.sh I think you<br>
>are saying I would create a file<br>
>with this single line in it<br>
>* lirc ALL=NOPASSWD:/usr/local/bin/killgui.sh  *<br>
>This assumes I have figured out that the user is *lirc *as you suggested.<br>
>I just want to verify that the file is called  */etc/sudoers.d/killgui* and<br>
>not  */etc/sudoers.d/killgui.sh*<br>
You sound like I felt when I first tried using sudoers.  As usual, the<br>
man files are written as a reference for someone who already knows how<br>
to do it and just needs to confirm the details.  I never did find a<br>
really good tutorial on the net, but I did find examples on how to do<br>
it.  So I would not classify myself as an expert on the subject, but I<br>
can make it work when I need it.<br>
In most cases, the name of a config file in an *.d directory has no<br>
meaning except to the humans involved.  This is the case for<br>
/etc/sudoers.d.  So you can use whatever name you like for the<br>
/etc/sudoers.d config files.  Only the contents matters.  I consider<br>
it a bad idea to put .sh on a file name when that file is not, in<br>
fact, a shell script, hence why I dropped it in my examples.  The<br>
sudoers config files can contain as many lines of config as you like.<br>
The lines do not need to be related to each other.  See the<br>
/etc/sudoers file for examples.  At the end of that file, you will see<br>
where it has an include line that reads all the files in<br>
In the line "lirc ALL=NOPASSWD:/usr/local/bin/killgui.sh", the<br>
"/usr/local/bin/kullgui.sh" bit after the colon identifies the program<br>
or script that is being given sudo permissions.  The "ALL=NOPASSWD:"<br>
bit tells what sudo permissions are being given - it can do anything<br>
that sudo allows ("ALL") and it can do it without having to ask for a<br>
password ("NOPASSWD").  The "lirc" at the left hand side is who is<br>
allowed this sudo permission.  It is actually a comma separated list<br>
of usernames, group names (with % in front) and other things.  See<br>
"man sudoers" for the full syntax.  So specifying "lirc" says that<br>
these special sudo permissions only apply when the script or program<br>
is being run by user "lirc".<br>
The sudoers permissions just allow the specified program or script to<br>
be run using sudo.  As far as I know, there is no way to allow users<br>
who do not have the correct permissions to run systemctl to run it<br>
without using sudo.  So if you were to set up /bin/systemctl in an<br>
sudoers file, you would still need to run it using "sudo systemctl".<br>
If you really want to be able to run anything from a user, you could<br>
try adding that user to the root group.  I have never done this, so I<br>
do not know how well it would work.  And it clearly is a dangerous<br>
thing to do.<br>
If all you need is to be able to ssh to the box and execute any<br>
command you want to, then the obvious way to do that is to set it up<br>
so you can log in as root instead of your normal MythTV username.  To<br>
do that, you need to edit the /etc/ssh/sshd_config file and change the<br>
PermitRootLogin line to read:<br>
PermitRootLogin yes<br>
then restart the sshd daemon:<br>
sudo systemctl restart sshd<br>
Then, if you have not already done so, you need to add a password to<br>
the root account:<br>
sudo passwd<br>
For ease of use, you can make it the same password as the normal user<br>
on the MythTV box if you like.<br>
I normally do this bit of setup as the first thing I do on a new Linux<br>
system, as I always need full root access for something.<br>
If you do not have the above setup on a box, and so can not login as<br>
root directly, then it is still easy to use the root account.  Just<br>
login as a normal user that has sudo capability and run this command:<br>
sudo su<br>
You will be asked for the sudo password once, and will then be running<br>
as the root user.  The "su" command is "set user".  Without any<br>
options, it sets the user to "root".  This command usually works on<br>
things like Linux based routers too - it is very convenient once you<br>
have learnt it.  Unfortunately, it does not work on Android phones, as<br>
Android has been set up specifically to prevent it.<br><br></blockquote><div><br></div><div>It looks like this is pretty straightforward assuming I can figure out the user. Just to confirm</div><div><br></div>file: <b>/etc/sudoers.d/killgui</b></div><div class="gmail_quote">contents: <b>lirc ALL=NOPASSWD:/usr/local/bin/killgui.sh</b></div><div class="gmail_quote"><b><br></b></div><div class="gmail_quote">Then modify killgui.sh to remove the sudo</div><div class="gmail_quote"><b>dad@NewMyth:~$ more killgui.sh<br>#!/bin/bash<br>         while [  true  ]; do<br>                systemctl isolate multi-user.target<br>                if [ $? -eq 0 ]; then<br>                     systemctl isolate graphical.target<br>                     exit 0<br>                fi<br>                sleep 1<br>         done</b><br></div><div class="gmail_quote"><b><br></b></div><div class="gmail_quote">and call it</div><div class="gmail_quote"><b>config = sudo /etc/sudoers.d/killgui.sh &</b>  <br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">If I understand things correctly, lirc is not going to be the user because it is not in the list of users </div><div class="gmail_quote"><b>_apt<br>avahi<br>avahi-autoipd<br>backup<br>bin<br>colord<br>dad<br>daemon<br>dnsmasq<br>games<br>gnats<br>hplip<br>irc<br>kernoops<br>lightdm<br>list<br>lp<br>mail<br>man<br>messagebus<br>mysql<br>mythtv<br>news<br>nobody<br>ntp<br>proxy<br>pulse<br>root<br>rtkit<br>saned<br>sshd<br>sync<br>sys<br>syslog<br>systemd-bus-proxy<br>systemd-network<br>systemd-resolve<br>systemd-timesync<br>usbmux<br>uucp<br>uuidd<br>whoopsie<br>www-data</b><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The suggestion was to make a test file that has this line in it</div><div class="gmail_quote"><b>whoami  > somefile</b></div></div></blockquote><div><br></div><div><div style="font-family:monospace,monospace">ps auwwxf|grep lirc </div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">will list the user in the 1st column.  If lirc is running as root, you do not need sudo at all :)</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote">and call it with the remote and look at somefile to see who the user is.  According to the lirc documentation (which isn't always right) lirc runs as root. That would make my entry into sudoers.d as </div><div class="gmail_quote">  <b>root ALL=NOPASSWD:/usr/local/bin/killgui.sh</b><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">For reference. I start lircd in /etc/rc/local</div><div class="gmail_quote"><br></div><div class="gmail_quote"><b>killall lircd<br>lircd -H udp -d 5000</b><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The input for my remote is my HDHomerun. I never could figure out where lircd was started and consider what I did a hack but it works. Perhaps this means that I am running lircd as root.</div><div class="gmail_quote"><br></div><div class="gmail_quote">How am I doing?</div><div class="gmail_quote"><br></div><div class="gmail_quote">Allen</div></div></blockquote></div></div></blockquote><div><br></div><div>haha.  </div><div><br></div><div><b>root      1104  0.0  0.0   6352  1560 ?        Ss   Mar04   0:00 lircd -H udp -d 5000 </b></div><div><b><br></b></div><div>So all I need to do is call the script and I don't need to fool with sudoers at all. Well, that makes it easier.</div><div><br></div><div>Allen</div></div></div>