Default permissions on Linux home directories

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











up vote
4
down vote

favorite
1












This question Unix & Linux: permissions 755 on /home/ covers part of my question but:



Default permissions on a home directory are 755 in many instances. However that lets other users wander into your home folder and look at stuff.



Changing the permissions to 711 (rwx--x--x) means they can traverse folders but not see anything. This is required if you have authorized_keys for SSH - without it the SSH gives errors when trying to access the system using a public key.



Is there some way to set up the folders / directories so SSH can access authorized_keys, postfix / mail can access files it requires, the system can access config files but without all and sundry walking the system?



I can manually make the folder 711, set ~/.ssh/authorized_keys to 644 but remembering to do that every time for every config is prone to (my) mistakes.



I would have thought by default all files were private unless specifically shared but with two Ubuntu boxes (admittedly server boxes) everyone can read all newly created files. That seems a little off as a default setting.










share|improve this question



























    up vote
    4
    down vote

    favorite
    1












    This question Unix & Linux: permissions 755 on /home/ covers part of my question but:



    Default permissions on a home directory are 755 in many instances. However that lets other users wander into your home folder and look at stuff.



    Changing the permissions to 711 (rwx--x--x) means they can traverse folders but not see anything. This is required if you have authorized_keys for SSH - without it the SSH gives errors when trying to access the system using a public key.



    Is there some way to set up the folders / directories so SSH can access authorized_keys, postfix / mail can access files it requires, the system can access config files but without all and sundry walking the system?



    I can manually make the folder 711, set ~/.ssh/authorized_keys to 644 but remembering to do that every time for every config is prone to (my) mistakes.



    I would have thought by default all files were private unless specifically shared but with two Ubuntu boxes (admittedly server boxes) everyone can read all newly created files. That seems a little off as a default setting.










    share|improve this question

























      up vote
      4
      down vote

      favorite
      1









      up vote
      4
      down vote

      favorite
      1






      1





      This question Unix & Linux: permissions 755 on /home/ covers part of my question but:



      Default permissions on a home directory are 755 in many instances. However that lets other users wander into your home folder and look at stuff.



      Changing the permissions to 711 (rwx--x--x) means they can traverse folders but not see anything. This is required if you have authorized_keys for SSH - without it the SSH gives errors when trying to access the system using a public key.



      Is there some way to set up the folders / directories so SSH can access authorized_keys, postfix / mail can access files it requires, the system can access config files but without all and sundry walking the system?



      I can manually make the folder 711, set ~/.ssh/authorized_keys to 644 but remembering to do that every time for every config is prone to (my) mistakes.



      I would have thought by default all files were private unless specifically shared but with two Ubuntu boxes (admittedly server boxes) everyone can read all newly created files. That seems a little off as a default setting.










      share|improve this question















      This question Unix & Linux: permissions 755 on /home/ covers part of my question but:



      Default permissions on a home directory are 755 in many instances. However that lets other users wander into your home folder and look at stuff.



      Changing the permissions to 711 (rwx--x--x) means they can traverse folders but not see anything. This is required if you have authorized_keys for SSH - without it the SSH gives errors when trying to access the system using a public key.



      Is there some way to set up the folders / directories so SSH can access authorized_keys, postfix / mail can access files it requires, the system can access config files but without all and sundry walking the system?



      I can manually make the folder 711, set ~/.ssh/authorized_keys to 644 but remembering to do that every time for every config is prone to (my) mistakes.



      I would have thought by default all files were private unless specifically shared but with two Ubuntu boxes (admittedly server boxes) everyone can read all newly created files. That seems a little off as a default setting.







      linux permissions home






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 4 at 4:03









      Will B

      6717




      6717










      asked Oct 12 '16 at 3:14









      Shane

      23113




      23113




















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          4
          down vote



          accepted










          As noted in the manual by default home folders made with useradd copy the /etc/skel folder so if you change it's subfolder rights all users created after in with default useradd will have the desired rights. Same for adduser. Editing "UMASK" in /etc/login.defs will change the rights when creating home folders.



          If you want more user security you can encrypt home folders and put ssh keys in /etc/ssh/%u instead of /home/%u/.ssh/authorized_keys .






          share|improve this answer






















          • Thank you. Its strange, I've been using Linux server for years but never even considered the skel folder. Seems I had a blind spot in my knowledge. Thank you.
            – Shane
            Oct 13 '16 at 22:45










          • Sounds like the most polite RTFM I've ever received :) Thanks. Like i said it is a blind spot - most of my Linux experience is on servers, no requirements for other than root user to access it. I've debugged the most arcane issues with drivers, set up highly secure servers, but never had to deal with multi user access in over 16 years. That's all been handled by Samba, DB access but we don't do ssh, scp, ftp or log on access for users - ever. Until today. TMFR'd ;)
            – Shane
            Oct 16 '16 at 7:24










          • I don't see that in the referenced manual, nor does that seem to be the case.
            – Teekin
            Dec 9 '17 at 20:13










          • @user1133275, I was trying to solve a different problem, i.e. trying to change the default rights of the newly created home folder itself, not a folder within it, so I misunderstood your answer to say something that it doesn't (and appropriately, it didn't work for me). Your answer makes sense in light of the question. The solution to my problem is editing "UMASK" in /etc/login.defs, in case anyone else is interested.
            – Teekin
            Dec 15 '17 at 18:11











          • @user1133275: I downvoted it earlier, but I'd like to upvote it if you clarify that the answer regards folders within /etc/skel. The way it's now, it looks like /etc/skel's rights themselves would be copied to the newly created home folder, which is not the case. I can't upvote unless you edit it, so if you clarify it (and ping me), I'll upvote.
            – Teekin
            Dec 15 '17 at 18:13

















          up vote
          1
          down vote













          How the permissions should be set depend on the overall security policy and the use case. Back in the old days Unix machines were truly multi-user systems with several hundred users logged in concurrently via serial terminals (such as a DEC VT-220). In this scenario your point was an issue - sometimes. Unix was used a lot in academic environments such as universities where security was a lesser concern, at least lesser than seamless collaboration.



          Today Unix (esp. in the incarnation Linux) is used as server system, in which case restricting home directories (there won't be too many, anyway) is rather pointless. Or, it is used for the desktop, where there is typically one user, in which case restricting home directories is also rather pointless.



          Therefore, from a certain point of view you are right. Yet, it is largely irrelevant for most use cases (especially the single-user case) and their risk profile, and thus, home directory permissions 0755 are as ok as 0700, 0711 or 0777.



          Appendix



          However, even a single user may have several user accounts, e.g. a default one, one for online banking, and one for generic web surfing etc., such that accounts are used for a kind of sand-boxing. In such cases stricter permissions are in order.






          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: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            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%2f315799%2fdefault-permissions-on-linux-home-directories%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            4
            down vote



            accepted










            As noted in the manual by default home folders made with useradd copy the /etc/skel folder so if you change it's subfolder rights all users created after in with default useradd will have the desired rights. Same for adduser. Editing "UMASK" in /etc/login.defs will change the rights when creating home folders.



            If you want more user security you can encrypt home folders and put ssh keys in /etc/ssh/%u instead of /home/%u/.ssh/authorized_keys .






            share|improve this answer






















            • Thank you. Its strange, I've been using Linux server for years but never even considered the skel folder. Seems I had a blind spot in my knowledge. Thank you.
              – Shane
              Oct 13 '16 at 22:45










            • Sounds like the most polite RTFM I've ever received :) Thanks. Like i said it is a blind spot - most of my Linux experience is on servers, no requirements for other than root user to access it. I've debugged the most arcane issues with drivers, set up highly secure servers, but never had to deal with multi user access in over 16 years. That's all been handled by Samba, DB access but we don't do ssh, scp, ftp or log on access for users - ever. Until today. TMFR'd ;)
              – Shane
              Oct 16 '16 at 7:24










            • I don't see that in the referenced manual, nor does that seem to be the case.
              – Teekin
              Dec 9 '17 at 20:13










            • @user1133275, I was trying to solve a different problem, i.e. trying to change the default rights of the newly created home folder itself, not a folder within it, so I misunderstood your answer to say something that it doesn't (and appropriately, it didn't work for me). Your answer makes sense in light of the question. The solution to my problem is editing "UMASK" in /etc/login.defs, in case anyone else is interested.
              – Teekin
              Dec 15 '17 at 18:11











            • @user1133275: I downvoted it earlier, but I'd like to upvote it if you clarify that the answer regards folders within /etc/skel. The way it's now, it looks like /etc/skel's rights themselves would be copied to the newly created home folder, which is not the case. I can't upvote unless you edit it, so if you clarify it (and ping me), I'll upvote.
              – Teekin
              Dec 15 '17 at 18:13














            up vote
            4
            down vote



            accepted










            As noted in the manual by default home folders made with useradd copy the /etc/skel folder so if you change it's subfolder rights all users created after in with default useradd will have the desired rights. Same for adduser. Editing "UMASK" in /etc/login.defs will change the rights when creating home folders.



            If you want more user security you can encrypt home folders and put ssh keys in /etc/ssh/%u instead of /home/%u/.ssh/authorized_keys .






            share|improve this answer






















            • Thank you. Its strange, I've been using Linux server for years but never even considered the skel folder. Seems I had a blind spot in my knowledge. Thank you.
              – Shane
              Oct 13 '16 at 22:45










            • Sounds like the most polite RTFM I've ever received :) Thanks. Like i said it is a blind spot - most of my Linux experience is on servers, no requirements for other than root user to access it. I've debugged the most arcane issues with drivers, set up highly secure servers, but never had to deal with multi user access in over 16 years. That's all been handled by Samba, DB access but we don't do ssh, scp, ftp or log on access for users - ever. Until today. TMFR'd ;)
              – Shane
              Oct 16 '16 at 7:24










            • I don't see that in the referenced manual, nor does that seem to be the case.
              – Teekin
              Dec 9 '17 at 20:13










            • @user1133275, I was trying to solve a different problem, i.e. trying to change the default rights of the newly created home folder itself, not a folder within it, so I misunderstood your answer to say something that it doesn't (and appropriately, it didn't work for me). Your answer makes sense in light of the question. The solution to my problem is editing "UMASK" in /etc/login.defs, in case anyone else is interested.
              – Teekin
              Dec 15 '17 at 18:11











            • @user1133275: I downvoted it earlier, but I'd like to upvote it if you clarify that the answer regards folders within /etc/skel. The way it's now, it looks like /etc/skel's rights themselves would be copied to the newly created home folder, which is not the case. I can't upvote unless you edit it, so if you clarify it (and ping me), I'll upvote.
              – Teekin
              Dec 15 '17 at 18:13












            up vote
            4
            down vote



            accepted







            up vote
            4
            down vote



            accepted






            As noted in the manual by default home folders made with useradd copy the /etc/skel folder so if you change it's subfolder rights all users created after in with default useradd will have the desired rights. Same for adduser. Editing "UMASK" in /etc/login.defs will change the rights when creating home folders.



            If you want more user security you can encrypt home folders and put ssh keys in /etc/ssh/%u instead of /home/%u/.ssh/authorized_keys .






            share|improve this answer














            As noted in the manual by default home folders made with useradd copy the /etc/skel folder so if you change it's subfolder rights all users created after in with default useradd will have the desired rights. Same for adduser. Editing "UMASK" in /etc/login.defs will change the rights when creating home folders.



            If you want more user security you can encrypt home folders and put ssh keys in /etc/ssh/%u instead of /home/%u/.ssh/authorized_keys .







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Dec 16 '17 at 13:14

























            answered Oct 12 '16 at 3:24









            user1133275

            2,780516




            2,780516











            • Thank you. Its strange, I've been using Linux server for years but never even considered the skel folder. Seems I had a blind spot in my knowledge. Thank you.
              – Shane
              Oct 13 '16 at 22:45










            • Sounds like the most polite RTFM I've ever received :) Thanks. Like i said it is a blind spot - most of my Linux experience is on servers, no requirements for other than root user to access it. I've debugged the most arcane issues with drivers, set up highly secure servers, but never had to deal with multi user access in over 16 years. That's all been handled by Samba, DB access but we don't do ssh, scp, ftp or log on access for users - ever. Until today. TMFR'd ;)
              – Shane
              Oct 16 '16 at 7:24










            • I don't see that in the referenced manual, nor does that seem to be the case.
              – Teekin
              Dec 9 '17 at 20:13










            • @user1133275, I was trying to solve a different problem, i.e. trying to change the default rights of the newly created home folder itself, not a folder within it, so I misunderstood your answer to say something that it doesn't (and appropriately, it didn't work for me). Your answer makes sense in light of the question. The solution to my problem is editing "UMASK" in /etc/login.defs, in case anyone else is interested.
              – Teekin
              Dec 15 '17 at 18:11











            • @user1133275: I downvoted it earlier, but I'd like to upvote it if you clarify that the answer regards folders within /etc/skel. The way it's now, it looks like /etc/skel's rights themselves would be copied to the newly created home folder, which is not the case. I can't upvote unless you edit it, so if you clarify it (and ping me), I'll upvote.
              – Teekin
              Dec 15 '17 at 18:13
















            • Thank you. Its strange, I've been using Linux server for years but never even considered the skel folder. Seems I had a blind spot in my knowledge. Thank you.
              – Shane
              Oct 13 '16 at 22:45










            • Sounds like the most polite RTFM I've ever received :) Thanks. Like i said it is a blind spot - most of my Linux experience is on servers, no requirements for other than root user to access it. I've debugged the most arcane issues with drivers, set up highly secure servers, but never had to deal with multi user access in over 16 years. That's all been handled by Samba, DB access but we don't do ssh, scp, ftp or log on access for users - ever. Until today. TMFR'd ;)
              – Shane
              Oct 16 '16 at 7:24










            • I don't see that in the referenced manual, nor does that seem to be the case.
              – Teekin
              Dec 9 '17 at 20:13










            • @user1133275, I was trying to solve a different problem, i.e. trying to change the default rights of the newly created home folder itself, not a folder within it, so I misunderstood your answer to say something that it doesn't (and appropriately, it didn't work for me). Your answer makes sense in light of the question. The solution to my problem is editing "UMASK" in /etc/login.defs, in case anyone else is interested.
              – Teekin
              Dec 15 '17 at 18:11











            • @user1133275: I downvoted it earlier, but I'd like to upvote it if you clarify that the answer regards folders within /etc/skel. The way it's now, it looks like /etc/skel's rights themselves would be copied to the newly created home folder, which is not the case. I can't upvote unless you edit it, so if you clarify it (and ping me), I'll upvote.
              – Teekin
              Dec 15 '17 at 18:13















            Thank you. Its strange, I've been using Linux server for years but never even considered the skel folder. Seems I had a blind spot in my knowledge. Thank you.
            – Shane
            Oct 13 '16 at 22:45




            Thank you. Its strange, I've been using Linux server for years but never even considered the skel folder. Seems I had a blind spot in my knowledge. Thank you.
            – Shane
            Oct 13 '16 at 22:45












            Sounds like the most polite RTFM I've ever received :) Thanks. Like i said it is a blind spot - most of my Linux experience is on servers, no requirements for other than root user to access it. I've debugged the most arcane issues with drivers, set up highly secure servers, but never had to deal with multi user access in over 16 years. That's all been handled by Samba, DB access but we don't do ssh, scp, ftp or log on access for users - ever. Until today. TMFR'd ;)
            – Shane
            Oct 16 '16 at 7:24




            Sounds like the most polite RTFM I've ever received :) Thanks. Like i said it is a blind spot - most of my Linux experience is on servers, no requirements for other than root user to access it. I've debugged the most arcane issues with drivers, set up highly secure servers, but never had to deal with multi user access in over 16 years. That's all been handled by Samba, DB access but we don't do ssh, scp, ftp or log on access for users - ever. Until today. TMFR'd ;)
            – Shane
            Oct 16 '16 at 7:24












            I don't see that in the referenced manual, nor does that seem to be the case.
            – Teekin
            Dec 9 '17 at 20:13




            I don't see that in the referenced manual, nor does that seem to be the case.
            – Teekin
            Dec 9 '17 at 20:13












            @user1133275, I was trying to solve a different problem, i.e. trying to change the default rights of the newly created home folder itself, not a folder within it, so I misunderstood your answer to say something that it doesn't (and appropriately, it didn't work for me). Your answer makes sense in light of the question. The solution to my problem is editing "UMASK" in /etc/login.defs, in case anyone else is interested.
            – Teekin
            Dec 15 '17 at 18:11





            @user1133275, I was trying to solve a different problem, i.e. trying to change the default rights of the newly created home folder itself, not a folder within it, so I misunderstood your answer to say something that it doesn't (and appropriately, it didn't work for me). Your answer makes sense in light of the question. The solution to my problem is editing "UMASK" in /etc/login.defs, in case anyone else is interested.
            – Teekin
            Dec 15 '17 at 18:11













            @user1133275: I downvoted it earlier, but I'd like to upvote it if you clarify that the answer regards folders within /etc/skel. The way it's now, it looks like /etc/skel's rights themselves would be copied to the newly created home folder, which is not the case. I can't upvote unless you edit it, so if you clarify it (and ping me), I'll upvote.
            – Teekin
            Dec 15 '17 at 18:13




            @user1133275: I downvoted it earlier, but I'd like to upvote it if you clarify that the answer regards folders within /etc/skel. The way it's now, it looks like /etc/skel's rights themselves would be copied to the newly created home folder, which is not the case. I can't upvote unless you edit it, so if you clarify it (and ping me), I'll upvote.
            – Teekin
            Dec 15 '17 at 18:13












            up vote
            1
            down vote













            How the permissions should be set depend on the overall security policy and the use case. Back in the old days Unix machines were truly multi-user systems with several hundred users logged in concurrently via serial terminals (such as a DEC VT-220). In this scenario your point was an issue - sometimes. Unix was used a lot in academic environments such as universities where security was a lesser concern, at least lesser than seamless collaboration.



            Today Unix (esp. in the incarnation Linux) is used as server system, in which case restricting home directories (there won't be too many, anyway) is rather pointless. Or, it is used for the desktop, where there is typically one user, in which case restricting home directories is also rather pointless.



            Therefore, from a certain point of view you are right. Yet, it is largely irrelevant for most use cases (especially the single-user case) and their risk profile, and thus, home directory permissions 0755 are as ok as 0700, 0711 or 0777.



            Appendix



            However, even a single user may have several user accounts, e.g. a default one, one for online banking, and one for generic web surfing etc., such that accounts are used for a kind of sand-boxing. In such cases stricter permissions are in order.






            share|improve this answer
























              up vote
              1
              down vote













              How the permissions should be set depend on the overall security policy and the use case. Back in the old days Unix machines were truly multi-user systems with several hundred users logged in concurrently via serial terminals (such as a DEC VT-220). In this scenario your point was an issue - sometimes. Unix was used a lot in academic environments such as universities where security was a lesser concern, at least lesser than seamless collaboration.



              Today Unix (esp. in the incarnation Linux) is used as server system, in which case restricting home directories (there won't be too many, anyway) is rather pointless. Or, it is used for the desktop, where there is typically one user, in which case restricting home directories is also rather pointless.



              Therefore, from a certain point of view you are right. Yet, it is largely irrelevant for most use cases (especially the single-user case) and their risk profile, and thus, home directory permissions 0755 are as ok as 0700, 0711 or 0777.



              Appendix



              However, even a single user may have several user accounts, e.g. a default one, one for online banking, and one for generic web surfing etc., such that accounts are used for a kind of sand-boxing. In such cases stricter permissions are in order.






              share|improve this answer






















                up vote
                1
                down vote










                up vote
                1
                down vote









                How the permissions should be set depend on the overall security policy and the use case. Back in the old days Unix machines were truly multi-user systems with several hundred users logged in concurrently via serial terminals (such as a DEC VT-220). In this scenario your point was an issue - sometimes. Unix was used a lot in academic environments such as universities where security was a lesser concern, at least lesser than seamless collaboration.



                Today Unix (esp. in the incarnation Linux) is used as server system, in which case restricting home directories (there won't be too many, anyway) is rather pointless. Or, it is used for the desktop, where there is typically one user, in which case restricting home directories is also rather pointless.



                Therefore, from a certain point of view you are right. Yet, it is largely irrelevant for most use cases (especially the single-user case) and their risk profile, and thus, home directory permissions 0755 are as ok as 0700, 0711 or 0777.



                Appendix



                However, even a single user may have several user accounts, e.g. a default one, one for online banking, and one for generic web surfing etc., such that accounts are used for a kind of sand-boxing. In such cases stricter permissions are in order.






                share|improve this answer












                How the permissions should be set depend on the overall security policy and the use case. Back in the old days Unix machines were truly multi-user systems with several hundred users logged in concurrently via serial terminals (such as a DEC VT-220). In this scenario your point was an issue - sometimes. Unix was used a lot in academic environments such as universities where security was a lesser concern, at least lesser than seamless collaboration.



                Today Unix (esp. in the incarnation Linux) is used as server system, in which case restricting home directories (there won't be too many, anyway) is rather pointless. Or, it is used for the desktop, where there is typically one user, in which case restricting home directories is also rather pointless.



                Therefore, from a certain point of view you are right. Yet, it is largely irrelevant for most use cases (especially the single-user case) and their risk profile, and thus, home directory permissions 0755 are as ok as 0700, 0711 or 0777.



                Appendix



                However, even a single user may have several user accounts, e.g. a default one, one for online banking, and one for generic web surfing etc., such that accounts are used for a kind of sand-boxing. In such cases stricter permissions are in order.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Oct 26 '16 at 10:07









                countermode

                5,19841943




                5,19841943



























                    draft saved

                    draft discarded
















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f315799%2fdefault-permissions-on-linux-home-directories%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown






                    Popular posts from this blog

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

                    Displaying single band from multi-band raster using QGIS

                    How many registers does an x86_64 CPU actually have?