Read-only filesystem - Considerations and Loss of Functionality

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











up vote
0
down vote

favorite












I'm creating an embedded system using Buildroot. Currently, my Buildroot configuration ensures the rootfs is remounted as read/write during startup. However I would like to remove this feature and keep my rootfs as read-only.



I have a few questions regarding this:




How do I change a user's password? This would require changing /etc/passwd & /etc/shadow.



How do I change the timezone? This would require changing /etc/localtime.



How do I create ssh keys for sshd? ssh-keygen creates the keys in /etc/ssh/



According to the Filesystem Hierarchy Standard, a Linux system is required to function with a read-only /etc/ directory, but it seems I'm finding a distinct loss of functionality as described above.




Secondly, after specifying that the rootfs is to remain read-only in my Buildroot configuration, it elects to mount /var/ as a tmpfs (in RAM, so it is writable)



But, this is volatile, how can I ensure runtime files (which I need to save) aren't lost on reboot or unexpected power-loss?



I'm using UBIFS, in my embedded system. Am I required to create a read/write UBI volume which I use as persistent storage? Is this the standard in embedded systems?




And finally, should I re-evaluate my idea to use a read-only rootfs at all? Given I am using UBI, and as wear-levelling is implemented across all the UBI volumes (the exist on the same device, of course), will I receive any benefit in making my rootfs read-only?







share|improve this question























    up vote
    0
    down vote

    favorite












    I'm creating an embedded system using Buildroot. Currently, my Buildroot configuration ensures the rootfs is remounted as read/write during startup. However I would like to remove this feature and keep my rootfs as read-only.



    I have a few questions regarding this:




    How do I change a user's password? This would require changing /etc/passwd & /etc/shadow.



    How do I change the timezone? This would require changing /etc/localtime.



    How do I create ssh keys for sshd? ssh-keygen creates the keys in /etc/ssh/



    According to the Filesystem Hierarchy Standard, a Linux system is required to function with a read-only /etc/ directory, but it seems I'm finding a distinct loss of functionality as described above.




    Secondly, after specifying that the rootfs is to remain read-only in my Buildroot configuration, it elects to mount /var/ as a tmpfs (in RAM, so it is writable)



    But, this is volatile, how can I ensure runtime files (which I need to save) aren't lost on reboot or unexpected power-loss?



    I'm using UBIFS, in my embedded system. Am I required to create a read/write UBI volume which I use as persistent storage? Is this the standard in embedded systems?




    And finally, should I re-evaluate my idea to use a read-only rootfs at all? Given I am using UBI, and as wear-levelling is implemented across all the UBI volumes (the exist on the same device, of course), will I receive any benefit in making my rootfs read-only?







    share|improve this question





















      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I'm creating an embedded system using Buildroot. Currently, my Buildroot configuration ensures the rootfs is remounted as read/write during startup. However I would like to remove this feature and keep my rootfs as read-only.



      I have a few questions regarding this:




      How do I change a user's password? This would require changing /etc/passwd & /etc/shadow.



      How do I change the timezone? This would require changing /etc/localtime.



      How do I create ssh keys for sshd? ssh-keygen creates the keys in /etc/ssh/



      According to the Filesystem Hierarchy Standard, a Linux system is required to function with a read-only /etc/ directory, but it seems I'm finding a distinct loss of functionality as described above.




      Secondly, after specifying that the rootfs is to remain read-only in my Buildroot configuration, it elects to mount /var/ as a tmpfs (in RAM, so it is writable)



      But, this is volatile, how can I ensure runtime files (which I need to save) aren't lost on reboot or unexpected power-loss?



      I'm using UBIFS, in my embedded system. Am I required to create a read/write UBI volume which I use as persistent storage? Is this the standard in embedded systems?




      And finally, should I re-evaluate my idea to use a read-only rootfs at all? Given I am using UBI, and as wear-levelling is implemented across all the UBI volumes (the exist on the same device, of course), will I receive any benefit in making my rootfs read-only?







      share|improve this question











      I'm creating an embedded system using Buildroot. Currently, my Buildroot configuration ensures the rootfs is remounted as read/write during startup. However I would like to remove this feature and keep my rootfs as read-only.



      I have a few questions regarding this:




      How do I change a user's password? This would require changing /etc/passwd & /etc/shadow.



      How do I change the timezone? This would require changing /etc/localtime.



      How do I create ssh keys for sshd? ssh-keygen creates the keys in /etc/ssh/



      According to the Filesystem Hierarchy Standard, a Linux system is required to function with a read-only /etc/ directory, but it seems I'm finding a distinct loss of functionality as described above.




      Secondly, after specifying that the rootfs is to remain read-only in my Buildroot configuration, it elects to mount /var/ as a tmpfs (in RAM, so it is writable)



      But, this is volatile, how can I ensure runtime files (which I need to save) aren't lost on reboot or unexpected power-loss?



      I'm using UBIFS, in my embedded system. Am I required to create a read/write UBI volume which I use as persistent storage? Is this the standard in embedded systems?




      And finally, should I re-evaluate my idea to use a read-only rootfs at all? Given I am using UBI, and as wear-levelling is implemented across all the UBI volumes (the exist on the same device, of course), will I receive any benefit in making my rootfs read-only?









      share|improve this question










      share|improve this question




      share|improve this question









      asked Apr 29 at 13:47









      Mattmatician

      11




      11




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          0
          down vote













          Keeping the filesystem mounted as readonly esures, that nothing is modified in an unexpected manner.



          To allow certain operation it is required to work with specific file system partitions:
          - System partition: readonly
          - User partition: writable



          Losing the user patition may only revert the embedded device to default state, but may not result in a permanent inacessible device.



          To allow certain operations i. E. changing passwords, it is required to symlink specific files to the user partition.
          - /etc/passwd -> /mnt/user/passwd
          - /etc/ssh -> /mnt/user/ssh
          - /etc/localtime -> /mnt/user/localtime



          To make the password access more robust, it may be a good idea to redirect passwd to tmpfs instead and then fetch the password from the user partition during startup.



          The aproach may lead to issues regarding the timezone. It may be required to patch tzdata to directly use /mnt/user/localtime if double linking results in an error:
          /etc/localtime -> /mnt/user/localtime -> /usr/share/zoneinfo ...






          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%2f440735%2fread-only-filesystem-considerations-and-loss-of-functionality%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













            Keeping the filesystem mounted as readonly esures, that nothing is modified in an unexpected manner.



            To allow certain operation it is required to work with specific file system partitions:
            - System partition: readonly
            - User partition: writable



            Losing the user patition may only revert the embedded device to default state, but may not result in a permanent inacessible device.



            To allow certain operations i. E. changing passwords, it is required to symlink specific files to the user partition.
            - /etc/passwd -> /mnt/user/passwd
            - /etc/ssh -> /mnt/user/ssh
            - /etc/localtime -> /mnt/user/localtime



            To make the password access more robust, it may be a good idea to redirect passwd to tmpfs instead and then fetch the password from the user partition during startup.



            The aproach may lead to issues regarding the timezone. It may be required to patch tzdata to directly use /mnt/user/localtime if double linking results in an error:
            /etc/localtime -> /mnt/user/localtime -> /usr/share/zoneinfo ...






            share|improve this answer

























              up vote
              0
              down vote













              Keeping the filesystem mounted as readonly esures, that nothing is modified in an unexpected manner.



              To allow certain operation it is required to work with specific file system partitions:
              - System partition: readonly
              - User partition: writable



              Losing the user patition may only revert the embedded device to default state, but may not result in a permanent inacessible device.



              To allow certain operations i. E. changing passwords, it is required to symlink specific files to the user partition.
              - /etc/passwd -> /mnt/user/passwd
              - /etc/ssh -> /mnt/user/ssh
              - /etc/localtime -> /mnt/user/localtime



              To make the password access more robust, it may be a good idea to redirect passwd to tmpfs instead and then fetch the password from the user partition during startup.



              The aproach may lead to issues regarding the timezone. It may be required to patch tzdata to directly use /mnt/user/localtime if double linking results in an error:
              /etc/localtime -> /mnt/user/localtime -> /usr/share/zoneinfo ...






              share|improve this answer























                up vote
                0
                down vote










                up vote
                0
                down vote









                Keeping the filesystem mounted as readonly esures, that nothing is modified in an unexpected manner.



                To allow certain operation it is required to work with specific file system partitions:
                - System partition: readonly
                - User partition: writable



                Losing the user patition may only revert the embedded device to default state, but may not result in a permanent inacessible device.



                To allow certain operations i. E. changing passwords, it is required to symlink specific files to the user partition.
                - /etc/passwd -> /mnt/user/passwd
                - /etc/ssh -> /mnt/user/ssh
                - /etc/localtime -> /mnt/user/localtime



                To make the password access more robust, it may be a good idea to redirect passwd to tmpfs instead and then fetch the password from the user partition during startup.



                The aproach may lead to issues regarding the timezone. It may be required to patch tzdata to directly use /mnt/user/localtime if double linking results in an error:
                /etc/localtime -> /mnt/user/localtime -> /usr/share/zoneinfo ...






                share|improve this answer













                Keeping the filesystem mounted as readonly esures, that nothing is modified in an unexpected manner.



                To allow certain operation it is required to work with specific file system partitions:
                - System partition: readonly
                - User partition: writable



                Losing the user patition may only revert the embedded device to default state, but may not result in a permanent inacessible device.



                To allow certain operations i. E. changing passwords, it is required to symlink specific files to the user partition.
                - /etc/passwd -> /mnt/user/passwd
                - /etc/ssh -> /mnt/user/ssh
                - /etc/localtime -> /mnt/user/localtime



                To make the password access more robust, it may be a good idea to redirect passwd to tmpfs instead and then fetch the password from the user partition during startup.



                The aproach may lead to issues regarding the timezone. It may be required to patch tzdata to directly use /mnt/user/localtime if double linking results in an error:
                /etc/localtime -> /mnt/user/localtime -> /usr/share/zoneinfo ...







                share|improve this answer













                share|improve this answer



                share|improve this answer











                answered Aug 6 at 9:01









                tb-free

                1




                1






















                     

                    draft saved


                    draft discarded


























                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f440735%2fread-only-filesystem-considerations-and-loss-of-functionality%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    Peggy Mitchell

                    Palaiologos

                    The Forum (Inglewood, California)