Default permissions on Linux home directories
Clash Royale CLAN TAG#URR8PPP
up vote
4
down vote
favorite
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
edited Dec 4 at 4:03
Will B
6717
asked Oct 12 '16 at 3:14
Shane
23113
add a comment |
up vote
4
down vote
favorite
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
edited Dec 4 at 4:03
Will B
6717
asked Oct 12 '16 at 3:14
Shane
23113
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
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
edited Dec 4 at 4:03
Will B
6717
asked Oct 12 '16 at 3:14
Shane
23113
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
linux permissions home
edited Dec 4 at 4:03
Will B
6717
asked Oct 12 '16 at 3:14
Shane
23113
edited Dec 4 at 4:03
Will B
6717
asked Oct 12 '16 at 3:14
Shane
23113
edited Dec 4 at 4:03
Will B
6717
edited Dec 4 at 4:03
Will B
6717
edited Dec 4 at 4:03
Will B
6717
6717
asked Oct 12 '16 at 3:14
Shane
23113
asked Oct 12 '16 at 3:14
Shane
23113
asked Oct 12 '16 at 3:14
Shane
23113
23113
add a comment |
add a comment |
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 .
answered Oct 12 '16 at 3:24
user1133275
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
|
show 1 more comment
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.
answered Oct 26 '16 at 10:07
countermode
5,19841943
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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 .
answered Oct 12 '16 at 3:24
user1133275
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
|
show 1 more comment
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 .
answered Oct 12 '16 at 3:24
user1133275
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
|
show 1 more comment
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 .
answered Oct 12 '16 at 3:24
user1133275
2,780516
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 .
answered Oct 12 '16 at 3:24
user1133275
2,780516
edited Dec 16 '17 at 13:14
answered Oct 12 '16 at 3:24
user1133275
2,780516
answered Oct 12 '16 at 3:24
user1133275
2,780516
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
|
show 1 more comment
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
|
show 1 more comment
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.
answered Oct 26 '16 at 10:07
countermode
5,19841943
add a comment |
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.
answered Oct 26 '16 at 10:07
countermode
5,19841943
add a comment |
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.
answered Oct 26 '16 at 10:07
countermode
5,19841943
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.
answered Oct 26 '16 at 10:07
countermode
5,19841943
answered Oct 26 '16 at 10:07
countermode
5,19841943
answered Oct 26 '16 at 10:07
countermode
5,19841943
answered Oct 26 '16 at 10:07
countermode
5,19841943
5,19841943
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
