How to change permission of anonymous pipe?
Clash Royale CLAN TAG#URR8PPP
I've the script which loads the SSH key from the variable (as part of script in CI environment) in order to not keep the private file in the public repository, however ssh-add
complains about the wrong permissions (and it seems it's not possible to bypass it). So my approach is to find the method of changing the permission of anonymous pipe which is created on the fly.
For example:
$ stat <(:)
File: ‘/dev/fd/63’
Size: 0 Blocks: 0 IO Block: 512 fifo
Device: 397f3928h/964639016d Inode: 818277067 Links: 0
Access: (0660/prw-rw----) Uid: ( 501/ kenorb) Gid: ( 20/ staff)
Access: 2015-10-10 22:33:30.498640000 +0100
Modify: 2015-10-10 22:33:30.498640000 +0100
Change: 2015-10-10 22:33:30.498640000 +0100
Birth: 2015-10-10 22:33:30.498640000 +0100
shows 0660
permission. I've checked my umask
and it seems it has nothing to do with that.
Here is a simple test (on OS X, which by default has 0660):
$ ssh-add <(cat ~/.ssh/id_rsa)
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0660 for '/dev/fd/63' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
On Linux it seems to work, because it's 0500
by default. Where this permission is controlled from?
To clarify, I'm not looking to change the permission of any file, as I'd like to use an anonymous pipe.
The question is:
How do I temporary change the permission of a pipe?
bash permissions pipe umask
add a comment |
I've the script which loads the SSH key from the variable (as part of script in CI environment) in order to not keep the private file in the public repository, however ssh-add
complains about the wrong permissions (and it seems it's not possible to bypass it). So my approach is to find the method of changing the permission of anonymous pipe which is created on the fly.
For example:
$ stat <(:)
File: ‘/dev/fd/63’
Size: 0 Blocks: 0 IO Block: 512 fifo
Device: 397f3928h/964639016d Inode: 818277067 Links: 0
Access: (0660/prw-rw----) Uid: ( 501/ kenorb) Gid: ( 20/ staff)
Access: 2015-10-10 22:33:30.498640000 +0100
Modify: 2015-10-10 22:33:30.498640000 +0100
Change: 2015-10-10 22:33:30.498640000 +0100
Birth: 2015-10-10 22:33:30.498640000 +0100
shows 0660
permission. I've checked my umask
and it seems it has nothing to do with that.
Here is a simple test (on OS X, which by default has 0660):
$ ssh-add <(cat ~/.ssh/id_rsa)
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0660 for '/dev/fd/63' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
On Linux it seems to work, because it's 0500
by default. Where this permission is controlled from?
To clarify, I'm not looking to change the permission of any file, as I'd like to use an anonymous pipe.
The question is:
How do I temporary change the permission of a pipe?
bash permissions pipe umask
1
A FIFO is a named pipe. You're having a problem because you have an (anonymous) pipe, not a FIFO.
– Gilles
Oct 11 '15 at 21:09
add a comment |
I've the script which loads the SSH key from the variable (as part of script in CI environment) in order to not keep the private file in the public repository, however ssh-add
complains about the wrong permissions (and it seems it's not possible to bypass it). So my approach is to find the method of changing the permission of anonymous pipe which is created on the fly.
For example:
$ stat <(:)
File: ‘/dev/fd/63’
Size: 0 Blocks: 0 IO Block: 512 fifo
Device: 397f3928h/964639016d Inode: 818277067 Links: 0
Access: (0660/prw-rw----) Uid: ( 501/ kenorb) Gid: ( 20/ staff)
Access: 2015-10-10 22:33:30.498640000 +0100
Modify: 2015-10-10 22:33:30.498640000 +0100
Change: 2015-10-10 22:33:30.498640000 +0100
Birth: 2015-10-10 22:33:30.498640000 +0100
shows 0660
permission. I've checked my umask
and it seems it has nothing to do with that.
Here is a simple test (on OS X, which by default has 0660):
$ ssh-add <(cat ~/.ssh/id_rsa)
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0660 for '/dev/fd/63' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
On Linux it seems to work, because it's 0500
by default. Where this permission is controlled from?
To clarify, I'm not looking to change the permission of any file, as I'd like to use an anonymous pipe.
The question is:
How do I temporary change the permission of a pipe?
bash permissions pipe umask
I've the script which loads the SSH key from the variable (as part of script in CI environment) in order to not keep the private file in the public repository, however ssh-add
complains about the wrong permissions (and it seems it's not possible to bypass it). So my approach is to find the method of changing the permission of anonymous pipe which is created on the fly.
For example:
$ stat <(:)
File: ‘/dev/fd/63’
Size: 0 Blocks: 0 IO Block: 512 fifo
Device: 397f3928h/964639016d Inode: 818277067 Links: 0
Access: (0660/prw-rw----) Uid: ( 501/ kenorb) Gid: ( 20/ staff)
Access: 2015-10-10 22:33:30.498640000 +0100
Modify: 2015-10-10 22:33:30.498640000 +0100
Change: 2015-10-10 22:33:30.498640000 +0100
Birth: 2015-10-10 22:33:30.498640000 +0100
shows 0660
permission. I've checked my umask
and it seems it has nothing to do with that.
Here is a simple test (on OS X, which by default has 0660):
$ ssh-add <(cat ~/.ssh/id_rsa)
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0660 for '/dev/fd/63' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
On Linux it seems to work, because it's 0500
by default. Where this permission is controlled from?
To clarify, I'm not looking to change the permission of any file, as I'd like to use an anonymous pipe.
The question is:
How do I temporary change the permission of a pipe?
bash permissions pipe umask
bash permissions pipe umask
edited Apr 13 '17 at 12:36
Community♦
1
1
asked Oct 10 '15 at 22:07
kenorbkenorb
8,856372110
8,856372110
1
A FIFO is a named pipe. You're having a problem because you have an (anonymous) pipe, not a FIFO.
– Gilles
Oct 11 '15 at 21:09
add a comment |
1
A FIFO is a named pipe. You're having a problem because you have an (anonymous) pipe, not a FIFO.
– Gilles
Oct 11 '15 at 21:09
1
1
A FIFO is a named pipe. You're having a problem because you have an (anonymous) pipe, not a FIFO.
– Gilles
Oct 11 '15 at 21:09
A FIFO is a named pipe. You're having a problem because you have an (anonymous) pipe, not a FIFO.
– Gilles
Oct 11 '15 at 21:09
add a comment |
2 Answers
2
active
oldest
votes
So far I've found the following workaround using named FIFO:
$ mkfifo -m 600 fifo
$ cat ~/.ssh/id_rsa >fifo | ssh-add fifo
Identity added: fifo (fifo)
where the option -m
sets the FIFO permission.
add a comment |
You may be able to wrap ssh-add
in a program which does a chmod
on the /dev/fd/N
path or fchmod
on the file descriptor.
For example, on a Linux machine where I don't get any complaint from ssh-add
using the default permissions, I'm able to reproduce the error by doing this:
perl -e 'chmod 0777, $ARGV[0];exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
If that reproduces the problem, then this should solve it:
perl -e 'chmod 0600, $ARGV[0];exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
The chmod
is supplied with a pathname like /proc/self/fd/11
but it changes the permissions on the actual pipe inode (since chmod doesn't work on symlinks). This should have the same effect, but using fchmod:
perl -e 'open P, "<", $ARGV[0]; chmod 0600, *P;close P;exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
This one should have the same effect, using fchmod and taking advantage of the fact that the pathname is in a predictable format to avoid the extra open:
perl -e '$ARGV[0] =~ m,^(?:/proc/self|/dev)/fd/(d+)z, and $^F=$1 and open P, "<&=$1" and chmod 0600, *P;exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
Those perl scripts would look less ugly as C programs; converting them is simple once you identify one that works in your target environment.
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',
autoActivateHeartbeat: false,
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%2f235290%2fhow-to-change-permission-of-anonymous-pipe%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
So far I've found the following workaround using named FIFO:
$ mkfifo -m 600 fifo
$ cat ~/.ssh/id_rsa >fifo | ssh-add fifo
Identity added: fifo (fifo)
where the option -m
sets the FIFO permission.
add a comment |
So far I've found the following workaround using named FIFO:
$ mkfifo -m 600 fifo
$ cat ~/.ssh/id_rsa >fifo | ssh-add fifo
Identity added: fifo (fifo)
where the option -m
sets the FIFO permission.
add a comment |
So far I've found the following workaround using named FIFO:
$ mkfifo -m 600 fifo
$ cat ~/.ssh/id_rsa >fifo | ssh-add fifo
Identity added: fifo (fifo)
where the option -m
sets the FIFO permission.
So far I've found the following workaround using named FIFO:
$ mkfifo -m 600 fifo
$ cat ~/.ssh/id_rsa >fifo | ssh-add fifo
Identity added: fifo (fifo)
where the option -m
sets the FIFO permission.
edited Feb 15 at 14:29
David Anderson
1033
1033
answered Oct 10 '15 at 23:14
kenorbkenorb
8,856372110
8,856372110
add a comment |
add a comment |
You may be able to wrap ssh-add
in a program which does a chmod
on the /dev/fd/N
path or fchmod
on the file descriptor.
For example, on a Linux machine where I don't get any complaint from ssh-add
using the default permissions, I'm able to reproduce the error by doing this:
perl -e 'chmod 0777, $ARGV[0];exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
If that reproduces the problem, then this should solve it:
perl -e 'chmod 0600, $ARGV[0];exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
The chmod
is supplied with a pathname like /proc/self/fd/11
but it changes the permissions on the actual pipe inode (since chmod doesn't work on symlinks). This should have the same effect, but using fchmod:
perl -e 'open P, "<", $ARGV[0]; chmod 0600, *P;close P;exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
This one should have the same effect, using fchmod and taking advantage of the fact that the pathname is in a predictable format to avoid the extra open:
perl -e '$ARGV[0] =~ m,^(?:/proc/self|/dev)/fd/(d+)z, and $^F=$1 and open P, "<&=$1" and chmod 0600, *P;exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
Those perl scripts would look less ugly as C programs; converting them is simple once you identify one that works in your target environment.
add a comment |
You may be able to wrap ssh-add
in a program which does a chmod
on the /dev/fd/N
path or fchmod
on the file descriptor.
For example, on a Linux machine where I don't get any complaint from ssh-add
using the default permissions, I'm able to reproduce the error by doing this:
perl -e 'chmod 0777, $ARGV[0];exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
If that reproduces the problem, then this should solve it:
perl -e 'chmod 0600, $ARGV[0];exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
The chmod
is supplied with a pathname like /proc/self/fd/11
but it changes the permissions on the actual pipe inode (since chmod doesn't work on symlinks). This should have the same effect, but using fchmod:
perl -e 'open P, "<", $ARGV[0]; chmod 0600, *P;close P;exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
This one should have the same effect, using fchmod and taking advantage of the fact that the pathname is in a predictable format to avoid the extra open:
perl -e '$ARGV[0] =~ m,^(?:/proc/self|/dev)/fd/(d+)z, and $^F=$1 and open P, "<&=$1" and chmod 0600, *P;exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
Those perl scripts would look less ugly as C programs; converting them is simple once you identify one that works in your target environment.
add a comment |
You may be able to wrap ssh-add
in a program which does a chmod
on the /dev/fd/N
path or fchmod
on the file descriptor.
For example, on a Linux machine where I don't get any complaint from ssh-add
using the default permissions, I'm able to reproduce the error by doing this:
perl -e 'chmod 0777, $ARGV[0];exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
If that reproduces the problem, then this should solve it:
perl -e 'chmod 0600, $ARGV[0];exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
The chmod
is supplied with a pathname like /proc/self/fd/11
but it changes the permissions on the actual pipe inode (since chmod doesn't work on symlinks). This should have the same effect, but using fchmod:
perl -e 'open P, "<", $ARGV[0]; chmod 0600, *P;close P;exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
This one should have the same effect, using fchmod and taking advantage of the fact that the pathname is in a predictable format to avoid the extra open:
perl -e '$ARGV[0] =~ m,^(?:/proc/self|/dev)/fd/(d+)z, and $^F=$1 and open P, "<&=$1" and chmod 0600, *P;exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
Those perl scripts would look less ugly as C programs; converting them is simple once you identify one that works in your target environment.
You may be able to wrap ssh-add
in a program which does a chmod
on the /dev/fd/N
path or fchmod
on the file descriptor.
For example, on a Linux machine where I don't get any complaint from ssh-add
using the default permissions, I'm able to reproduce the error by doing this:
perl -e 'chmod 0777, $ARGV[0];exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
If that reproduces the problem, then this should solve it:
perl -e 'chmod 0600, $ARGV[0];exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
The chmod
is supplied with a pathname like /proc/self/fd/11
but it changes the permissions on the actual pipe inode (since chmod doesn't work on symlinks). This should have the same effect, but using fchmod:
perl -e 'open P, "<", $ARGV[0]; chmod 0600, *P;close P;exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
This one should have the same effect, using fchmod and taking advantage of the fact that the pathname is in a predictable format to avoid the extra open:
perl -e '$ARGV[0] =~ m,^(?:/proc/self|/dev)/fd/(d+)z, and $^F=$1 and open P, "<&=$1" and chmod 0600, *P;exec "ssh-add", $ARGV[0];' <(cat ~/.ssh/id_rsa)
Those perl scripts would look less ugly as C programs; converting them is simple once you identify one that works in your target environment.
answered Oct 11 '15 at 23:44
Wumpus Q. WumbleyWumpus Q. Wumbley
4,7101322
4,7101322
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.
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%2f235290%2fhow-to-change-permission-of-anonymous-pipe%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
1
A FIFO is a named pipe. You're having a problem because you have an (anonymous) pipe, not a FIFO.
– Gilles
Oct 11 '15 at 21:09