Systemd fails to start service as root

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












I'm trying to start a service to sign the VirtualBox kernel modules, following https://nidomiro.de/2018/04/automatic-virtualbox-module-signing-for-uefi/



After adjusting the paths referenced in the bash script for Fedora, the script works when run manually as root. However, the service always fails:



$ systemctl status sign-virtualbox.service 
● sign-virtualbox.service - Signing VirtualBox Kernel Modules for UEFI
Loaded: loaded (/etc/systemd/system/sign-virtualbox.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code)
Process: 3018 ExecStart=/root/module-signing/sign-vbox-modules.sh (code=exited, status=203/EXEC)
Main PID: 3018 (code=exited, status=203/EXEC)


The output of sudo journalctl -xe says sign-virtualbox.service: Failed at step EXEC spawning /root/module-signing/sign-vbox-modules.sh: Permission denied



File permissions:



$ sudo ls -l /root/module-signing/sign-vbox-modules.sh
-rwx------. 1 root root 309 Aug 7 11:35 /root/module-signing/sign-vbox-modules.sh


Since the service is started as root, there shouldn't be a permissions issue, should there?










share|improve this question





















  • When you realize why this duplicates unix.stackexchange.com/questions/208736 , you will know what to do. (-:
    – JdeBP
    Aug 7 at 16:10










  • @JdeBP How do I determine the correct SELinux context to assign to the files? The answer to the question to which you linked doesn't really answer the question beyond "SELinux contexts exist, get yours right"
    – zaen
    Aug 7 at 19:03















up vote
1
down vote

favorite












I'm trying to start a service to sign the VirtualBox kernel modules, following https://nidomiro.de/2018/04/automatic-virtualbox-module-signing-for-uefi/



After adjusting the paths referenced in the bash script for Fedora, the script works when run manually as root. However, the service always fails:



$ systemctl status sign-virtualbox.service 
● sign-virtualbox.service - Signing VirtualBox Kernel Modules for UEFI
Loaded: loaded (/etc/systemd/system/sign-virtualbox.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code)
Process: 3018 ExecStart=/root/module-signing/sign-vbox-modules.sh (code=exited, status=203/EXEC)
Main PID: 3018 (code=exited, status=203/EXEC)


The output of sudo journalctl -xe says sign-virtualbox.service: Failed at step EXEC spawning /root/module-signing/sign-vbox-modules.sh: Permission denied



File permissions:



$ sudo ls -l /root/module-signing/sign-vbox-modules.sh
-rwx------. 1 root root 309 Aug 7 11:35 /root/module-signing/sign-vbox-modules.sh


Since the service is started as root, there shouldn't be a permissions issue, should there?










share|improve this question





















  • When you realize why this duplicates unix.stackexchange.com/questions/208736 , you will know what to do. (-:
    – JdeBP
    Aug 7 at 16:10










  • @JdeBP How do I determine the correct SELinux context to assign to the files? The answer to the question to which you linked doesn't really answer the question beyond "SELinux contexts exist, get yours right"
    – zaen
    Aug 7 at 19:03













up vote
1
down vote

favorite









up vote
1
down vote

favorite











I'm trying to start a service to sign the VirtualBox kernel modules, following https://nidomiro.de/2018/04/automatic-virtualbox-module-signing-for-uefi/



After adjusting the paths referenced in the bash script for Fedora, the script works when run manually as root. However, the service always fails:



$ systemctl status sign-virtualbox.service 
● sign-virtualbox.service - Signing VirtualBox Kernel Modules for UEFI
Loaded: loaded (/etc/systemd/system/sign-virtualbox.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code)
Process: 3018 ExecStart=/root/module-signing/sign-vbox-modules.sh (code=exited, status=203/EXEC)
Main PID: 3018 (code=exited, status=203/EXEC)


The output of sudo journalctl -xe says sign-virtualbox.service: Failed at step EXEC spawning /root/module-signing/sign-vbox-modules.sh: Permission denied



File permissions:



$ sudo ls -l /root/module-signing/sign-vbox-modules.sh
-rwx------. 1 root root 309 Aug 7 11:35 /root/module-signing/sign-vbox-modules.sh


Since the service is started as root, there shouldn't be a permissions issue, should there?










share|improve this question













I'm trying to start a service to sign the VirtualBox kernel modules, following https://nidomiro.de/2018/04/automatic-virtualbox-module-signing-for-uefi/



After adjusting the paths referenced in the bash script for Fedora, the script works when run manually as root. However, the service always fails:



$ systemctl status sign-virtualbox.service 
● sign-virtualbox.service - Signing VirtualBox Kernel Modules for UEFI
Loaded: loaded (/etc/systemd/system/sign-virtualbox.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code)
Process: 3018 ExecStart=/root/module-signing/sign-vbox-modules.sh (code=exited, status=203/EXEC)
Main PID: 3018 (code=exited, status=203/EXEC)


The output of sudo journalctl -xe says sign-virtualbox.service: Failed at step EXEC spawning /root/module-signing/sign-vbox-modules.sh: Permission denied



File permissions:



$ sudo ls -l /root/module-signing/sign-vbox-modules.sh
-rwx------. 1 root root 309 Aug 7 11:35 /root/module-signing/sign-vbox-modules.sh


Since the service is started as root, there shouldn't be a permissions issue, should there?







systemd






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Aug 7 at 15:58









zaen

154




154











  • When you realize why this duplicates unix.stackexchange.com/questions/208736 , you will know what to do. (-:
    – JdeBP
    Aug 7 at 16:10










  • @JdeBP How do I determine the correct SELinux context to assign to the files? The answer to the question to which you linked doesn't really answer the question beyond "SELinux contexts exist, get yours right"
    – zaen
    Aug 7 at 19:03

















  • When you realize why this duplicates unix.stackexchange.com/questions/208736 , you will know what to do. (-:
    – JdeBP
    Aug 7 at 16:10










  • @JdeBP How do I determine the correct SELinux context to assign to the files? The answer to the question to which you linked doesn't really answer the question beyond "SELinux contexts exist, get yours right"
    – zaen
    Aug 7 at 19:03
















When you realize why this duplicates unix.stackexchange.com/questions/208736 , you will know what to do. (-:
– JdeBP
Aug 7 at 16:10




When you realize why this duplicates unix.stackexchange.com/questions/208736 , you will know what to do. (-:
– JdeBP
Aug 7 at 16:10












@JdeBP How do I determine the correct SELinux context to assign to the files? The answer to the question to which you linked doesn't really answer the question beyond "SELinux contexts exist, get yours right"
– zaen
Aug 7 at 19:03





@JdeBP How do I determine the correct SELinux context to assign to the files? The answer to the question to which you linked doesn't really answer the question beyond "SELinux contexts exist, get yours right"
– zaen
Aug 7 at 19:03











1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted










Execution of the binary is probably being blocked by SELinux. You can confirm that from the journal logs or perhaps from the audit logs (in /var/log/audit/audit.log) searching for "avc" errors.



To solve this problem, I'd recommend you host this script from a directory where scripts and binaries are typically located, such as /usr/local/bin, instead of under the home directory of the root user.



Once you move this script there, run restorecon on it to get it to the proper SELinux type (which should be system_u:object_r:bin_t:s0 or similar.)



So:



mv /root/module-signing/sign-vbox-modules.sh /usr/local/bin/
restorecon /usr/local/bin/sign-vbox-modules.sh


And edit your systemd service file to update the path.



And if you want to inspect that it has an appropriate SELinux type:



ls -lZ /usr/local/bin/sign-vbox-modules.sh





share|improve this answer




















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f461103%2fsystemd-fails-to-start-service-as-root%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote



    accepted










    Execution of the binary is probably being blocked by SELinux. You can confirm that from the journal logs or perhaps from the audit logs (in /var/log/audit/audit.log) searching for "avc" errors.



    To solve this problem, I'd recommend you host this script from a directory where scripts and binaries are typically located, such as /usr/local/bin, instead of under the home directory of the root user.



    Once you move this script there, run restorecon on it to get it to the proper SELinux type (which should be system_u:object_r:bin_t:s0 or similar.)



    So:



    mv /root/module-signing/sign-vbox-modules.sh /usr/local/bin/
    restorecon /usr/local/bin/sign-vbox-modules.sh


    And edit your systemd service file to update the path.



    And if you want to inspect that it has an appropriate SELinux type:



    ls -lZ /usr/local/bin/sign-vbox-modules.sh





    share|improve this answer
























      up vote
      0
      down vote



      accepted










      Execution of the binary is probably being blocked by SELinux. You can confirm that from the journal logs or perhaps from the audit logs (in /var/log/audit/audit.log) searching for "avc" errors.



      To solve this problem, I'd recommend you host this script from a directory where scripts and binaries are typically located, such as /usr/local/bin, instead of under the home directory of the root user.



      Once you move this script there, run restorecon on it to get it to the proper SELinux type (which should be system_u:object_r:bin_t:s0 or similar.)



      So:



      mv /root/module-signing/sign-vbox-modules.sh /usr/local/bin/
      restorecon /usr/local/bin/sign-vbox-modules.sh


      And edit your systemd service file to update the path.



      And if you want to inspect that it has an appropriate SELinux type:



      ls -lZ /usr/local/bin/sign-vbox-modules.sh





      share|improve this answer






















        up vote
        0
        down vote



        accepted







        up vote
        0
        down vote



        accepted






        Execution of the binary is probably being blocked by SELinux. You can confirm that from the journal logs or perhaps from the audit logs (in /var/log/audit/audit.log) searching for "avc" errors.



        To solve this problem, I'd recommend you host this script from a directory where scripts and binaries are typically located, such as /usr/local/bin, instead of under the home directory of the root user.



        Once you move this script there, run restorecon on it to get it to the proper SELinux type (which should be system_u:object_r:bin_t:s0 or similar.)



        So:



        mv /root/module-signing/sign-vbox-modules.sh /usr/local/bin/
        restorecon /usr/local/bin/sign-vbox-modules.sh


        And edit your systemd service file to update the path.



        And if you want to inspect that it has an appropriate SELinux type:



        ls -lZ /usr/local/bin/sign-vbox-modules.sh





        share|improve this answer












        Execution of the binary is probably being blocked by SELinux. You can confirm that from the journal logs or perhaps from the audit logs (in /var/log/audit/audit.log) searching for "avc" errors.



        To solve this problem, I'd recommend you host this script from a directory where scripts and binaries are typically located, such as /usr/local/bin, instead of under the home directory of the root user.



        Once you move this script there, run restorecon on it to get it to the proper SELinux type (which should be system_u:object_r:bin_t:s0 or similar.)



        So:



        mv /root/module-signing/sign-vbox-modules.sh /usr/local/bin/
        restorecon /usr/local/bin/sign-vbox-modules.sh


        And edit your systemd service file to update the path.



        And if you want to inspect that it has an appropriate SELinux type:



        ls -lZ /usr/local/bin/sign-vbox-modules.sh






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Aug 8 at 2:02









        Filipe Brandenburger

        3,734622




        3,734622



























             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f461103%2fsystemd-fails-to-start-service-as-root%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay