cryptsetup - how does it print prompt bypassing stdout/stdin redirection?
Clash Royale CLAN TAG#URR8PPP
up vote
4
down vote
favorite
I just noticed that no matter which cryptsetup FDs are forwarded to /dev/null it still shows prompt for password. For example this still shows prompt:
cryptsetyp luksOpen /dev/sdXY name >/dev/null 2>/dev/null
How can you display in terminal message that cannot be redirected to file using standard redirection?
I'd like to get such functionality in bash script as I use stdout to return result to mother script but I'd still like to display interactive prompt - is it possible to do so using bash?
file-descriptors
asked Oct 21 '17 at 19:23
Lapsio
584515
add a comment |Â
up vote
4
down vote
favorite
I just noticed that no matter which cryptsetup FDs are forwarded to /dev/null it still shows prompt for password. For example this still shows prompt:
cryptsetyp luksOpen /dev/sdXY name >/dev/null 2>/dev/null
How can you display in terminal message that cannot be redirected to file using standard redirection?
I'd like to get such functionality in bash script as I use stdout to return result to mother script but I'd still like to display interactive prompt - is it possible to do so using bash?
file-descriptors
asked Oct 21 '17 at 19:23
Lapsio
584515
You're asking for an explanation, so a solution wouldn't address that. However, if you want to circumvent password input from terminal and forcecryptsetupto read the password from standard input, use the--key-file=-option. This however won't strip trailing newline characters like it does for terminal password sources.
– David Foerster
Oct 21 '17 at 20:04
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I just noticed that no matter which cryptsetup FDs are forwarded to /dev/null it still shows prompt for password. For example this still shows prompt:
cryptsetyp luksOpen /dev/sdXY name >/dev/null 2>/dev/null
How can you display in terminal message that cannot be redirected to file using standard redirection?
I'd like to get such functionality in bash script as I use stdout to return result to mother script but I'd still like to display interactive prompt - is it possible to do so using bash?
file-descriptors
asked Oct 21 '17 at 19:23
Lapsio
584515
I just noticed that no matter which cryptsetup FDs are forwarded to /dev/null it still shows prompt for password. For example this still shows prompt:
cryptsetyp luksOpen /dev/sdXY name >/dev/null 2>/dev/null
How can you display in terminal message that cannot be redirected to file using standard redirection?
I'd like to get such functionality in bash script as I use stdout to return result to mother script but I'd still like to display interactive prompt - is it possible to do so using bash?
file-descriptors
asked Oct 21 '17 at 19:23
Lapsio
584515
asked Oct 21 '17 at 19:23
Lapsio
584515
asked Oct 21 '17 at 19:23
Lapsio
584515
asked Oct 21 '17 at 19:23
Lapsio
584515
584515
You're asking for an explanation, so a solution wouldn't address that. However, if you want to circumvent password input from terminal and forcecryptsetupto read the password from standard input, use the--key-file=-option. This however won't strip trailing newline characters like it does for terminal password sources.
– David Foerster
Oct 21 '17 at 20:04
add a comment |Â
You're asking for an explanation, so a solution wouldn't address that. However, if you want to circumvent password input from terminal and forcecryptsetupto read the password from standard input, use the--key-file=-option. This however won't strip trailing newline characters like it does for terminal password sources.
– David Foerster
Oct 21 '17 at 20:04
You're asking for an explanation, so a solution wouldn't address that. However, if you want to circumvent password input from terminal and force
cryptsetup to read the password from standard input, use the --key-file=- option. This however won't strip trailing newline characters like it does for terminal password sources.– David Foerster
Oct 21 '17 at 20:04
You're asking for an explanation, so a solution wouldn't address that. However, if you want to circumvent password input from terminal and force
cryptsetup to read the password from standard input, use the --key-file=- option. This however won't strip trailing newline characters like it does for terminal password sources.– David Foerster
Oct 21 '17 at 20:04
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
3
down vote
accepted
Presumably, It writes directly to /dev/tty (at any rate, you can get the same behavior)
#!/bin/bash
# set up the new file descriptor
# I have no idea why this needs exec, please tell me.
exec 3> /dev/tty
# test
echo "Stdout"
echo "Stderr" >&2
echo "Directly to tty" >&3
alternatively, you can simply do:
echo "Directly to tty" >/dev/tty
$ ./foo.sh >/dev/null 2>/dev/null
Directly to tty
read still works if you do this.
answered Oct 21 '17 at 19:37
Blacksilver
17412
what doesexec 3> /filedo? In a sense why there's eval.
– Lapsio
Oct 21 '17 at 19:49
It sets up the new file descriptor. Editing to clarify.
– Blacksilver
Oct 21 '17 at 19:51
I mean why not just3> /filewithoutexec.
– Lapsio
Oct 21 '17 at 19:53
1
I haven't the foggiest idea. It just doesn't work.
– Blacksilver
Oct 21 '17 at 19:54
1
Exec is required because it's part of the shell syntax (e.g. runhelp execin bash). Normally a redirection only affects a single command's file descriptors. You are redirecting the shell's file descriptors, which is a distinct operation.
– Kevin
Oct 21 '17 at 20:18
add a comment |Â
up vote
6
down vote
If you strace it, you will probably see that it uses /dev/tty directly.
...
open("/dev/tty", O_RDWR) = 6
ioctl(6, TCGETS, B38400 opost isig icanon echo ...) = 0
write(6, "Enter passphrase for .......: ", 30) = 30
ioctl(6, SNDCTL_TMR_CONTINUE or TCSETSF, B38400 opost isig icanon -echo ...) = 0
...
In the source code (utils_crypt.c):
static int interactive_pass(const char *prompt, char *pass, size_t maxlen,
long timeout)
{
[...]
/* Read and write to /dev/tty if available */
infd = open("/dev/tty", O_RDWR);
if (infd == -1)
infd = STDIN_FILENO;
outfd = STDERR_FILENO;
else
outfd = infd;
if (tcgetattr(infd, &orig))
goto out_err;
So it tests for /dev/tty by opening it, and if that works it uses that. If it fails, it falls back to regular stdin, stdout, and then you wouldn't see the prompt anymore.
As for the /dev/tty, it's the terminal of the process, for more detail see man 4 tty.
answered Oct 21 '17 at 19:41
frostschutz
24.7k14774
Relevant xkcd: xkcd.com/292
– Blacksilver
Oct 21 '17 at 19:50
@Blacksilver I wouldn't say it's bad practice. It probably has something to do with security. After all it's really critical app security wise. The harder it is to hijack output the better.
– Lapsio
Oct 21 '17 at 19:56
Yeah, I know. I'm just doing my obligatory duty.
– Blacksilver
Oct 21 '17 at 19:58
And now I don't know why exactly did they use tty directly and what are security implications and I can't find the answer. My whole day is ruined now in blind desire for useless knowledge...
– Lapsio
Oct 21 '17 at 20:03
@Blacksilver: Goto is required in languages like C which don't have C++ destructors nor thetry/finallyof higher-level languages. If you don't use goto, you have to duplicate your cleanup logic, which is messy and error-prone.
– Kevin
Oct 21 '17 at 20:21
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
Presumably, It writes directly to /dev/tty (at any rate, you can get the same behavior)
#!/bin/bash
# set up the new file descriptor
# I have no idea why this needs exec, please tell me.
exec 3> /dev/tty
# test
echo "Stdout"
echo "Stderr" >&2
echo "Directly to tty" >&3
alternatively, you can simply do:
echo "Directly to tty" >/dev/tty
$ ./foo.sh >/dev/null 2>/dev/null
Directly to tty
read still works if you do this.
answered Oct 21 '17 at 19:37
Blacksilver
17412
what doesexec 3> /filedo? In a sense why there's eval.
– Lapsio
Oct 21 '17 at 19:49
It sets up the new file descriptor. Editing to clarify.
– Blacksilver
Oct 21 '17 at 19:51
I mean why not just3> /filewithoutexec.
– Lapsio
Oct 21 '17 at 19:53
1
I haven't the foggiest idea. It just doesn't work.
– Blacksilver
Oct 21 '17 at 19:54
1
Exec is required because it's part of the shell syntax (e.g. runhelp execin bash). Normally a redirection only affects a single command's file descriptors. You are redirecting the shell's file descriptors, which is a distinct operation.
– Kevin
Oct 21 '17 at 20:18
add a comment |Â
up vote
3
down vote
accepted
Presumably, It writes directly to /dev/tty (at any rate, you can get the same behavior)
#!/bin/bash
# set up the new file descriptor
# I have no idea why this needs exec, please tell me.
exec 3> /dev/tty
# test
echo "Stdout"
echo "Stderr" >&2
echo "Directly to tty" >&3
alternatively, you can simply do:
echo "Directly to tty" >/dev/tty
$ ./foo.sh >/dev/null 2>/dev/null
Directly to tty
read still works if you do this.
answered Oct 21 '17 at 19:37
Blacksilver
17412
what doesexec 3> /filedo? In a sense why there's eval.
– Lapsio
Oct 21 '17 at 19:49
It sets up the new file descriptor. Editing to clarify.
– Blacksilver
Oct 21 '17 at 19:51
I mean why not just3> /filewithoutexec.
– Lapsio
Oct 21 '17 at 19:53
1
I haven't the foggiest idea. It just doesn't work.
– Blacksilver
Oct 21 '17 at 19:54
1
Exec is required because it's part of the shell syntax (e.g. runhelp execin bash). Normally a redirection only affects a single command's file descriptors. You are redirecting the shell's file descriptors, which is a distinct operation.
– Kevin
Oct 21 '17 at 20:18
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
Presumably, It writes directly to /dev/tty (at any rate, you can get the same behavior)
#!/bin/bash
# set up the new file descriptor
# I have no idea why this needs exec, please tell me.
exec 3> /dev/tty
# test
echo "Stdout"
echo "Stderr" >&2
echo "Directly to tty" >&3
alternatively, you can simply do:
echo "Directly to tty" >/dev/tty
$ ./foo.sh >/dev/null 2>/dev/null
Directly to tty
read still works if you do this.
answered Oct 21 '17 at 19:37
Blacksilver
17412
Presumably, It writes directly to /dev/tty (at any rate, you can get the same behavior)
#!/bin/bash
# set up the new file descriptor
# I have no idea why this needs exec, please tell me.
exec 3> /dev/tty
# test
echo "Stdout"
echo "Stderr" >&2
echo "Directly to tty" >&3
alternatively, you can simply do:
echo "Directly to tty" >/dev/tty
$ ./foo.sh >/dev/null 2>/dev/null
Directly to tty
read still works if you do this.
answered Oct 21 '17 at 19:37
Blacksilver
17412
edited Oct 21 '17 at 19:54
answered Oct 21 '17 at 19:37
Blacksilver
17412
answered Oct 21 '17 at 19:37
Blacksilver
17412
answered Oct 21 '17 at 19:37
Blacksilver
17412
17412
what doesexec 3> /filedo? In a sense why there's eval.
– Lapsio
Oct 21 '17 at 19:49
It sets up the new file descriptor. Editing to clarify.
– Blacksilver
Oct 21 '17 at 19:51
I mean why not just3> /filewithoutexec.
– Lapsio
Oct 21 '17 at 19:53
1
I haven't the foggiest idea. It just doesn't work.
– Blacksilver
Oct 21 '17 at 19:54
1
Exec is required because it's part of the shell syntax (e.g. runhelp execin bash). Normally a redirection only affects a single command's file descriptors. You are redirecting the shell's file descriptors, which is a distinct operation.
– Kevin
Oct 21 '17 at 20:18
add a comment |Â
what doesexec 3> /filedo? In a sense why there's eval.
– Lapsio
Oct 21 '17 at 19:49
It sets up the new file descriptor. Editing to clarify.
– Blacksilver
Oct 21 '17 at 19:51
I mean why not just3> /filewithoutexec.
– Lapsio
Oct 21 '17 at 19:53
1
I haven't the foggiest idea. It just doesn't work.
– Blacksilver
Oct 21 '17 at 19:54
1
Exec is required because it's part of the shell syntax (e.g. runhelp execin bash). Normally a redirection only affects a single command's file descriptors. You are redirecting the shell's file descriptors, which is a distinct operation.
– Kevin
Oct 21 '17 at 20:18
what does
exec 3> /file do? In a sense why there's eval.– Lapsio
Oct 21 '17 at 19:49
what does
exec 3> /file do? In a sense why there's eval.– Lapsio
Oct 21 '17 at 19:49
It sets up the new file descriptor. Editing to clarify.
– Blacksilver
Oct 21 '17 at 19:51
It sets up the new file descriptor. Editing to clarify.
– Blacksilver
Oct 21 '17 at 19:51
I mean why not just
3> /file without exec.– Lapsio
Oct 21 '17 at 19:53
I mean why not just
3> /file without exec.– Lapsio
Oct 21 '17 at 19:53
1
1
I haven't the foggiest idea. It just doesn't work.
– Blacksilver
Oct 21 '17 at 19:54
I haven't the foggiest idea. It just doesn't work.
– Blacksilver
Oct 21 '17 at 19:54
1
1
Exec is required because it's part of the shell syntax (e.g. run
help exec in bash). Normally a redirection only affects a single command's file descriptors. You are redirecting the shell's file descriptors, which is a distinct operation.– Kevin
Oct 21 '17 at 20:18
Exec is required because it's part of the shell syntax (e.g. run
help exec in bash). Normally a redirection only affects a single command's file descriptors. You are redirecting the shell's file descriptors, which is a distinct operation.– Kevin
Oct 21 '17 at 20:18
add a comment |Â
up vote
6
down vote
If you strace it, you will probably see that it uses /dev/tty directly.
...
open("/dev/tty", O_RDWR) = 6
ioctl(6, TCGETS, B38400 opost isig icanon echo ...) = 0
write(6, "Enter passphrase for .......: ", 30) = 30
ioctl(6, SNDCTL_TMR_CONTINUE or TCSETSF, B38400 opost isig icanon -echo ...) = 0
...
In the source code (utils_crypt.c):
static int interactive_pass(const char *prompt, char *pass, size_t maxlen,
long timeout)
{
[...]
/* Read and write to /dev/tty if available */
infd = open("/dev/tty", O_RDWR);
if (infd == -1)
infd = STDIN_FILENO;
outfd = STDERR_FILENO;
else
outfd = infd;
if (tcgetattr(infd, &orig))
goto out_err;
So it tests for /dev/tty by opening it, and if that works it uses that. If it fails, it falls back to regular stdin, stdout, and then you wouldn't see the prompt anymore.
As for the /dev/tty, it's the terminal of the process, for more detail see man 4 tty.
answered Oct 21 '17 at 19:41
frostschutz
24.7k14774
Relevant xkcd: xkcd.com/292
– Blacksilver
Oct 21 '17 at 19:50
@Blacksilver I wouldn't say it's bad practice. It probably has something to do with security. After all it's really critical app security wise. The harder it is to hijack output the better.
– Lapsio
Oct 21 '17 at 19:56
Yeah, I know. I'm just doing my obligatory duty.
– Blacksilver
Oct 21 '17 at 19:58
And now I don't know why exactly did they use tty directly and what are security implications and I can't find the answer. My whole day is ruined now in blind desire for useless knowledge...
– Lapsio
Oct 21 '17 at 20:03
@Blacksilver: Goto is required in languages like C which don't have C++ destructors nor thetry/finallyof higher-level languages. If you don't use goto, you have to duplicate your cleanup logic, which is messy and error-prone.
– Kevin
Oct 21 '17 at 20:21
add a comment |Â
up vote
6
down vote
If you strace it, you will probably see that it uses /dev/tty directly.
...
open("/dev/tty", O_RDWR) = 6
ioctl(6, TCGETS, B38400 opost isig icanon echo ...) = 0
write(6, "Enter passphrase for .......: ", 30) = 30
ioctl(6, SNDCTL_TMR_CONTINUE or TCSETSF, B38400 opost isig icanon -echo ...) = 0
...
In the source code (utils_crypt.c):
static int interactive_pass(const char *prompt, char *pass, size_t maxlen,
long timeout)
{
[...]
/* Read and write to /dev/tty if available */
infd = open("/dev/tty", O_RDWR);
if (infd == -1)
infd = STDIN_FILENO;
outfd = STDERR_FILENO;
else
outfd = infd;
if (tcgetattr(infd, &orig))
goto out_err;
So it tests for /dev/tty by opening it, and if that works it uses that. If it fails, it falls back to regular stdin, stdout, and then you wouldn't see the prompt anymore.
As for the /dev/tty, it's the terminal of the process, for more detail see man 4 tty.
answered Oct 21 '17 at 19:41
frostschutz
24.7k14774
Relevant xkcd: xkcd.com/292
– Blacksilver
Oct 21 '17 at 19:50
@Blacksilver I wouldn't say it's bad practice. It probably has something to do with security. After all it's really critical app security wise. The harder it is to hijack output the better.
– Lapsio
Oct 21 '17 at 19:56
Yeah, I know. I'm just doing my obligatory duty.
– Blacksilver
Oct 21 '17 at 19:58
And now I don't know why exactly did they use tty directly and what are security implications and I can't find the answer. My whole day is ruined now in blind desire for useless knowledge...
– Lapsio
Oct 21 '17 at 20:03
@Blacksilver: Goto is required in languages like C which don't have C++ destructors nor thetry/finallyof higher-level languages. If you don't use goto, you have to duplicate your cleanup logic, which is messy and error-prone.
– Kevin
Oct 21 '17 at 20:21
add a comment |Â
up vote
6
down vote
up vote
6
down vote
If you strace it, you will probably see that it uses /dev/tty directly.
...
open("/dev/tty", O_RDWR) = 6
ioctl(6, TCGETS, B38400 opost isig icanon echo ...) = 0
write(6, "Enter passphrase for .......: ", 30) = 30
ioctl(6, SNDCTL_TMR_CONTINUE or TCSETSF, B38400 opost isig icanon -echo ...) = 0
...
In the source code (utils_crypt.c):
static int interactive_pass(const char *prompt, char *pass, size_t maxlen,
long timeout)
{
[...]
/* Read and write to /dev/tty if available */
infd = open("/dev/tty", O_RDWR);
if (infd == -1)
infd = STDIN_FILENO;
outfd = STDERR_FILENO;
else
outfd = infd;
if (tcgetattr(infd, &orig))
goto out_err;
So it tests for /dev/tty by opening it, and if that works it uses that. If it fails, it falls back to regular stdin, stdout, and then you wouldn't see the prompt anymore.
As for the /dev/tty, it's the terminal of the process, for more detail see man 4 tty.
answered Oct 21 '17 at 19:41
frostschutz
24.7k14774
If you strace it, you will probably see that it uses /dev/tty directly.
...
open("/dev/tty", O_RDWR) = 6
ioctl(6, TCGETS, B38400 opost isig icanon echo ...) = 0
write(6, "Enter passphrase for .......: ", 30) = 30
ioctl(6, SNDCTL_TMR_CONTINUE or TCSETSF, B38400 opost isig icanon -echo ...) = 0
...
In the source code (utils_crypt.c):
static int interactive_pass(const char *prompt, char *pass, size_t maxlen,
long timeout)
{
[...]
/* Read and write to /dev/tty if available */
infd = open("/dev/tty", O_RDWR);
if (infd == -1)
infd = STDIN_FILENO;
outfd = STDERR_FILENO;
else
outfd = infd;
if (tcgetattr(infd, &orig))
goto out_err;
So it tests for /dev/tty by opening it, and if that works it uses that. If it fails, it falls back to regular stdin, stdout, and then you wouldn't see the prompt anymore.
As for the /dev/tty, it's the terminal of the process, for more detail see man 4 tty.
answered Oct 21 '17 at 19:41
frostschutz
24.7k14774
answered Oct 21 '17 at 19:41
frostschutz
24.7k14774
answered Oct 21 '17 at 19:41
frostschutz
24.7k14774
answered Oct 21 '17 at 19:41
frostschutz
24.7k14774
24.7k14774
Relevant xkcd: xkcd.com/292
– Blacksilver
Oct 21 '17 at 19:50
@Blacksilver I wouldn't say it's bad practice. It probably has something to do with security. After all it's really critical app security wise. The harder it is to hijack output the better.
– Lapsio
Oct 21 '17 at 19:56
Yeah, I know. I'm just doing my obligatory duty.
– Blacksilver
Oct 21 '17 at 19:58
And now I don't know why exactly did they use tty directly and what are security implications and I can't find the answer. My whole day is ruined now in blind desire for useless knowledge...
– Lapsio
Oct 21 '17 at 20:03
@Blacksilver: Goto is required in languages like C which don't have C++ destructors nor thetry/finallyof higher-level languages. If you don't use goto, you have to duplicate your cleanup logic, which is messy and error-prone.
– Kevin
Oct 21 '17 at 20:21
add a comment |Â
Relevant xkcd: xkcd.com/292
– Blacksilver
Oct 21 '17 at 19:50
@Blacksilver I wouldn't say it's bad practice. It probably has something to do with security. After all it's really critical app security wise. The harder it is to hijack output the better.
– Lapsio
Oct 21 '17 at 19:56
Yeah, I know. I'm just doing my obligatory duty.
– Blacksilver
Oct 21 '17 at 19:58
And now I don't know why exactly did they use tty directly and what are security implications and I can't find the answer. My whole day is ruined now in blind desire for useless knowledge...
– Lapsio
Oct 21 '17 at 20:03
@Blacksilver: Goto is required in languages like C which don't have C++ destructors nor thetry/finallyof higher-level languages. If you don't use goto, you have to duplicate your cleanup logic, which is messy and error-prone.
– Kevin
Oct 21 '17 at 20:21
Relevant xkcd: xkcd.com/292
– Blacksilver
Oct 21 '17 at 19:50
Relevant xkcd: xkcd.com/292
– Blacksilver
Oct 21 '17 at 19:50
@Blacksilver I wouldn't say it's bad practice. It probably has something to do with security. After all it's really critical app security wise. The harder it is to hijack output the better.
– Lapsio
Oct 21 '17 at 19:56
@Blacksilver I wouldn't say it's bad practice. It probably has something to do with security. After all it's really critical app security wise. The harder it is to hijack output the better.
– Lapsio
Oct 21 '17 at 19:56
Yeah, I know. I'm just doing my obligatory duty.
– Blacksilver
Oct 21 '17 at 19:58
Yeah, I know. I'm just doing my obligatory duty.
– Blacksilver
Oct 21 '17 at 19:58
And now I don't know why exactly did they use tty directly and what are security implications and I can't find the answer. My whole day is ruined now in blind desire for useless knowledge...
– Lapsio
Oct 21 '17 at 20:03
And now I don't know why exactly did they use tty directly and what are security implications and I can't find the answer. My whole day is ruined now in blind desire for useless knowledge...
– Lapsio
Oct 21 '17 at 20:03
@Blacksilver: Goto is required in languages like C which don't have C++ destructors nor the
try/finally of higher-level languages. If you don't use goto, you have to duplicate your cleanup logic, which is messy and error-prone.– Kevin
Oct 21 '17 at 20:21
@Blacksilver: Goto is required in languages like C which don't have C++ destructors nor the
try/finally of higher-level languages. If you don't use goto, you have to duplicate your cleanup logic, which is messy and error-prone.– Kevin
Oct 21 '17 at 20:21
add a comment |Â
Â
draft saved
draft discarded
Â
draft saved
draft discarded
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%2f399604%2fcryptsetup-how-does-it-print-prompt-bypassing-stdout-stdin-redirection%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
You're asking for an explanation, so a solution wouldn't address that. However, if you want to circumvent password input from terminal and force
cryptsetupto read the password from standard input, use the--key-file=-option. This however won't strip trailing newline characters like it does for terminal password sources.– David Foerster
Oct 21 '17 at 20:04