Difference between directory and file permissions in this particular scenario
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
Recently I was learning SSH based authentication to connect to a web server.The post recommended certain file permissions.The .ssh folder of the local computer must have directory permission of 700 and the contents inside it for example the keys must have file permission of 640.
What doesn't make sense is if I am setting rwx permission for the owner and nothing for the group and others for the directory, then it means the group and others can't list or cd into the directory.Then what's the point of further setting a permission of 640 (ie rw for the group and nothing for others) for the files inside of it?The group or others can't anyway read or move into the directory in the first place.
files permissions
asked Nov 6 '17 at 17:26
Souvik Ray
12326
add a comment |Â
up vote
1
down vote
favorite
Recently I was learning SSH based authentication to connect to a web server.The post recommended certain file permissions.The .ssh folder of the local computer must have directory permission of 700 and the contents inside it for example the keys must have file permission of 640.
What doesn't make sense is if I am setting rwx permission for the owner and nothing for the group and others for the directory, then it means the group and others can't list or cd into the directory.Then what's the point of further setting a permission of 640 (ie rw for the group and nothing for others) for the files inside of it?The group or others can't anyway read or move into the directory in the first place.
files permissions
asked Nov 6 '17 at 17:26
Souvik Ray
12326
1
Well where I learned it it said that whatever you do you must make sure that nobody but you can read~/.ssh/id_rsa; normally, this is done by letting~/.sshbe the usual 0755 or 0750, and~/.ssh/id_rsa0600, but setting~/.sshto 0700 will also work if you can vouch that there is no hard link to~/.ssh/id_rsafrom elsewhere. Anyway, only the private key(s) are secret;~/.ssh/authorized_keysis not secret. Also, some (maybe obsolete) Unix variants did not enforce mode checking for directory traversal...
– AlexP
Nov 6 '17 at 18:20
@AlexP0755is acceptable for~/.ssh? I thought it had to be0700. Is that not correct?
– igal
Nov 6 '17 at 18:35
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Recently I was learning SSH based authentication to connect to a web server.The post recommended certain file permissions.The .ssh folder of the local computer must have directory permission of 700 and the contents inside it for example the keys must have file permission of 640.
What doesn't make sense is if I am setting rwx permission for the owner and nothing for the group and others for the directory, then it means the group and others can't list or cd into the directory.Then what's the point of further setting a permission of 640 (ie rw for the group and nothing for others) for the files inside of it?The group or others can't anyway read or move into the directory in the first place.
files permissions
asked Nov 6 '17 at 17:26
Souvik Ray
12326
Recently I was learning SSH based authentication to connect to a web server.The post recommended certain file permissions.The .ssh folder of the local computer must have directory permission of 700 and the contents inside it for example the keys must have file permission of 640.
What doesn't make sense is if I am setting rwx permission for the owner and nothing for the group and others for the directory, then it means the group and others can't list or cd into the directory.Then what's the point of further setting a permission of 640 (ie rw for the group and nothing for others) for the files inside of it?The group or others can't anyway read or move into the directory in the first place.
files permissions
asked Nov 6 '17 at 17:26
Souvik Ray
12326
edited Nov 6 '17 at 18:20
asked Nov 6 '17 at 17:26
Souvik Ray
12326
asked Nov 6 '17 at 17:26
Souvik Ray
12326
asked Nov 6 '17 at 17:26
Souvik Ray
12326
12326
1
Well where I learned it it said that whatever you do you must make sure that nobody but you can read~/.ssh/id_rsa; normally, this is done by letting~/.sshbe the usual 0755 or 0750, and~/.ssh/id_rsa0600, but setting~/.sshto 0700 will also work if you can vouch that there is no hard link to~/.ssh/id_rsafrom elsewhere. Anyway, only the private key(s) are secret;~/.ssh/authorized_keysis not secret. Also, some (maybe obsolete) Unix variants did not enforce mode checking for directory traversal...
– AlexP
Nov 6 '17 at 18:20
@AlexP0755is acceptable for~/.ssh? I thought it had to be0700. Is that not correct?
– igal
Nov 6 '17 at 18:35
add a comment |Â
1
Well where I learned it it said that whatever you do you must make sure that nobody but you can read~/.ssh/id_rsa; normally, this is done by letting~/.sshbe the usual 0755 or 0750, and~/.ssh/id_rsa0600, but setting~/.sshto 0700 will also work if you can vouch that there is no hard link to~/.ssh/id_rsafrom elsewhere. Anyway, only the private key(s) are secret;~/.ssh/authorized_keysis not secret. Also, some (maybe obsolete) Unix variants did not enforce mode checking for directory traversal...
– AlexP
Nov 6 '17 at 18:20
@AlexP0755is acceptable for~/.ssh? I thought it had to be0700. Is that not correct?
– igal
Nov 6 '17 at 18:35
1
1
Well where I learned it it said that whatever you do you must make sure that nobody but you can read
~/.ssh/id_rsa; normally, this is done by letting ~/.ssh be the usual 0755 or 0750, and ~/.ssh/id_rsa 0600, but setting ~/.ssh to 0700 will also work if you can vouch that there is no hard link to ~/.ssh/id_rsa from elsewhere. Anyway, only the private key(s) are secret; ~/.ssh/authorized_keys is not secret. Also, some (maybe obsolete) Unix variants did not enforce mode checking for directory traversal...– AlexP
Nov 6 '17 at 18:20
Well where I learned it it said that whatever you do you must make sure that nobody but you can read
~/.ssh/id_rsa; normally, this is done by letting ~/.ssh be the usual 0755 or 0750, and ~/.ssh/id_rsa 0600, but setting ~/.ssh to 0700 will also work if you can vouch that there is no hard link to ~/.ssh/id_rsa from elsewhere. Anyway, only the private key(s) are secret; ~/.ssh/authorized_keys is not secret. Also, some (maybe obsolete) Unix variants did not enforce mode checking for directory traversal...– AlexP
Nov 6 '17 at 18:20
@AlexP
0755 is acceptable for ~/.ssh? I thought it had to be 0700. Is that not correct?– igal
Nov 6 '17 at 18:35
@AlexP
0755 is acceptable for ~/.ssh? I thought it had to be 0700. Is that not correct?– igal
Nov 6 '17 at 18:35
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
You are correct that the permissions inside are functionally irrelevant with the given directory structure and permissions, but there's one thing you're missing. Hard links share permissions.
In your above example, if you create a hard link (not a symbolic link) pointing to ~/.ssh/id_rsa somewhere else, the resultant file will mirror the permissions from ~/.ssh/id_rsa, and thus people will be able to get to it if their user would have access either through your home directory, or through the new location.
As a result, the SSH requirement is actually less stringent than it technically should be (Ideally, your private keys in that directory need to have permissions of 0600, not 0640), but most people don't know or care about hard links any more (they're not hugely useful compared to symbolic links (which can cross filesystem boundaries), or reflinks (which will properly split the link on all cases when one of the links gets written to).
As for the other files, there is still some requirement for security there. In particular:
- The
.ssh/authorized_keysfile contains info on what other public keys you have access too. - The
.ssh/known_hostsfile contains info on what systems you have connected to (OpenSSH actually provides functionality to protect this without permissions using a one-way hash on the host names and IP addresses). - The public parts of your keys can be used to match with
.ssh/authorized_keyson other systems to associate accounts, or in theory to attack your private key (though this second case is mostly theoretical unless you're dealing with a government-level adversary).
All of those files can be used to figure out other potential locations to steal your information from, and thus should ideally be protected.
answered Nov 6 '17 at 20:07
Austin Hemmelgarn
5,1741915
Hey thanks a lot for the explanation and pointing out the vulnerabilities!Now atleast it makes sense how people can still get into the directory despite setting no permission at all.
– Souvik Ray
Nov 7 '17 at 19:38
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
You are correct that the permissions inside are functionally irrelevant with the given directory structure and permissions, but there's one thing you're missing. Hard links share permissions.
In your above example, if you create a hard link (not a symbolic link) pointing to ~/.ssh/id_rsa somewhere else, the resultant file will mirror the permissions from ~/.ssh/id_rsa, and thus people will be able to get to it if their user would have access either through your home directory, or through the new location.
As a result, the SSH requirement is actually less stringent than it technically should be (Ideally, your private keys in that directory need to have permissions of 0600, not 0640), but most people don't know or care about hard links any more (they're not hugely useful compared to symbolic links (which can cross filesystem boundaries), or reflinks (which will properly split the link on all cases when one of the links gets written to).
As for the other files, there is still some requirement for security there. In particular:
- The
.ssh/authorized_keysfile contains info on what other public keys you have access too. - The
.ssh/known_hostsfile contains info on what systems you have connected to (OpenSSH actually provides functionality to protect this without permissions using a one-way hash on the host names and IP addresses). - The public parts of your keys can be used to match with
.ssh/authorized_keyson other systems to associate accounts, or in theory to attack your private key (though this second case is mostly theoretical unless you're dealing with a government-level adversary).
All of those files can be used to figure out other potential locations to steal your information from, and thus should ideally be protected.
answered Nov 6 '17 at 20:07
Austin Hemmelgarn
5,1741915
Hey thanks a lot for the explanation and pointing out the vulnerabilities!Now atleast it makes sense how people can still get into the directory despite setting no permission at all.
– Souvik Ray
Nov 7 '17 at 19:38
add a comment |Â
up vote
2
down vote
accepted
You are correct that the permissions inside are functionally irrelevant with the given directory structure and permissions, but there's one thing you're missing. Hard links share permissions.
In your above example, if you create a hard link (not a symbolic link) pointing to ~/.ssh/id_rsa somewhere else, the resultant file will mirror the permissions from ~/.ssh/id_rsa, and thus people will be able to get to it if their user would have access either through your home directory, or through the new location.
As a result, the SSH requirement is actually less stringent than it technically should be (Ideally, your private keys in that directory need to have permissions of 0600, not 0640), but most people don't know or care about hard links any more (they're not hugely useful compared to symbolic links (which can cross filesystem boundaries), or reflinks (which will properly split the link on all cases when one of the links gets written to).
As for the other files, there is still some requirement for security there. In particular:
- The
.ssh/authorized_keysfile contains info on what other public keys you have access too. - The
.ssh/known_hostsfile contains info on what systems you have connected to (OpenSSH actually provides functionality to protect this without permissions using a one-way hash on the host names and IP addresses). - The public parts of your keys can be used to match with
.ssh/authorized_keyson other systems to associate accounts, or in theory to attack your private key (though this second case is mostly theoretical unless you're dealing with a government-level adversary).
All of those files can be used to figure out other potential locations to steal your information from, and thus should ideally be protected.
answered Nov 6 '17 at 20:07
Austin Hemmelgarn
5,1741915
Hey thanks a lot for the explanation and pointing out the vulnerabilities!Now atleast it makes sense how people can still get into the directory despite setting no permission at all.
– Souvik Ray
Nov 7 '17 at 19:38
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
You are correct that the permissions inside are functionally irrelevant with the given directory structure and permissions, but there's one thing you're missing. Hard links share permissions.
In your above example, if you create a hard link (not a symbolic link) pointing to ~/.ssh/id_rsa somewhere else, the resultant file will mirror the permissions from ~/.ssh/id_rsa, and thus people will be able to get to it if their user would have access either through your home directory, or through the new location.
As a result, the SSH requirement is actually less stringent than it technically should be (Ideally, your private keys in that directory need to have permissions of 0600, not 0640), but most people don't know or care about hard links any more (they're not hugely useful compared to symbolic links (which can cross filesystem boundaries), or reflinks (which will properly split the link on all cases when one of the links gets written to).
As for the other files, there is still some requirement for security there. In particular:
- The
.ssh/authorized_keysfile contains info on what other public keys you have access too. - The
.ssh/known_hostsfile contains info on what systems you have connected to (OpenSSH actually provides functionality to protect this without permissions using a one-way hash on the host names and IP addresses). - The public parts of your keys can be used to match with
.ssh/authorized_keyson other systems to associate accounts, or in theory to attack your private key (though this second case is mostly theoretical unless you're dealing with a government-level adversary).
All of those files can be used to figure out other potential locations to steal your information from, and thus should ideally be protected.
answered Nov 6 '17 at 20:07
Austin Hemmelgarn
5,1741915
You are correct that the permissions inside are functionally irrelevant with the given directory structure and permissions, but there's one thing you're missing. Hard links share permissions.
In your above example, if you create a hard link (not a symbolic link) pointing to ~/.ssh/id_rsa somewhere else, the resultant file will mirror the permissions from ~/.ssh/id_rsa, and thus people will be able to get to it if their user would have access either through your home directory, or through the new location.
As a result, the SSH requirement is actually less stringent than it technically should be (Ideally, your private keys in that directory need to have permissions of 0600, not 0640), but most people don't know or care about hard links any more (they're not hugely useful compared to symbolic links (which can cross filesystem boundaries), or reflinks (which will properly split the link on all cases when one of the links gets written to).
As for the other files, there is still some requirement for security there. In particular:
- The
.ssh/authorized_keysfile contains info on what other public keys you have access too. - The
.ssh/known_hostsfile contains info on what systems you have connected to (OpenSSH actually provides functionality to protect this without permissions using a one-way hash on the host names and IP addresses). - The public parts of your keys can be used to match with
.ssh/authorized_keyson other systems to associate accounts, or in theory to attack your private key (though this second case is mostly theoretical unless you're dealing with a government-level adversary).
All of those files can be used to figure out other potential locations to steal your information from, and thus should ideally be protected.
answered Nov 6 '17 at 20:07
Austin Hemmelgarn
5,1741915
answered Nov 6 '17 at 20:07
Austin Hemmelgarn
5,1741915
answered Nov 6 '17 at 20:07
Austin Hemmelgarn
5,1741915
answered Nov 6 '17 at 20:07
Austin Hemmelgarn
5,1741915
5,1741915
Hey thanks a lot for the explanation and pointing out the vulnerabilities!Now atleast it makes sense how people can still get into the directory despite setting no permission at all.
– Souvik Ray
Nov 7 '17 at 19:38
add a comment |Â
Hey thanks a lot for the explanation and pointing out the vulnerabilities!Now atleast it makes sense how people can still get into the directory despite setting no permission at all.
– Souvik Ray
Nov 7 '17 at 19:38
Hey thanks a lot for the explanation and pointing out the vulnerabilities!Now atleast it makes sense how people can still get into the directory despite setting no permission at all.
– Souvik Ray
Nov 7 '17 at 19:38
Hey thanks a lot for the explanation and pointing out the vulnerabilities!Now atleast it makes sense how people can still get into the directory despite setting no permission at all.
– Souvik Ray
Nov 7 '17 at 19:38
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f402881%2fdifference-between-directory-and-file-permissions-in-this-particular-scenario%23new-answer', 'question_page');
);
Post as a guest
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
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
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
1
Well where I learned it it said that whatever you do you must make sure that nobody but you can read
~/.ssh/id_rsa; normally, this is done by letting~/.sshbe the usual 0755 or 0750, and~/.ssh/id_rsa0600, but setting~/.sshto 0700 will also work if you can vouch that there is no hard link to~/.ssh/id_rsafrom elsewhere. Anyway, only the private key(s) are secret;~/.ssh/authorized_keysis not secret. Also, some (maybe obsolete) Unix variants did not enforce mode checking for directory traversal...– AlexP
Nov 6 '17 at 18:20
@AlexP
0755is acceptable for~/.ssh? I thought it had to be0700. Is that not correct?– igal
Nov 6 '17 at 18:35