How to make sense of non-interactive login shell?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
A non-interactive non-login shell is easy to understand, simply executing a shell script in Terminal will launched a non-interactive non-login shell that will run this shell script.
But I don't understand how non-interactive login shell works, if the shell is non-interactive, then you can't enter your login credentials when the shell is executed, so do you put your login credentials in the shell script or something?
linux shell
add a comment |Â
up vote
0
down vote
favorite
A non-interactive non-login shell is easy to understand, simply executing a shell script in Terminal will launched a non-interactive non-login shell that will run this shell script.
But I don't understand how non-interactive login shell works, if the shell is non-interactive, then you can't enter your login credentials when the shell is executed, so do you put your login credentials in the shell script or something?
linux shell
2
You generally don't give your credentials to the shell. When any login shell is executed you normally have already entered your login credentials - prompted eg. byssh
, a getty andlogin
or a display manager.
â Michaà  Politowski
Sep 25 '17 at 10:49
3
Question is in part answered by unix.stackexchange.com/questions/38175/â¦
â Kusalananda
Sep 25 '17 at 10:52
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
A non-interactive non-login shell is easy to understand, simply executing a shell script in Terminal will launched a non-interactive non-login shell that will run this shell script.
But I don't understand how non-interactive login shell works, if the shell is non-interactive, then you can't enter your login credentials when the shell is executed, so do you put your login credentials in the shell script or something?
linux shell
A non-interactive non-login shell is easy to understand, simply executing a shell script in Terminal will launched a non-interactive non-login shell that will run this shell script.
But I don't understand how non-interactive login shell works, if the shell is non-interactive, then you can't enter your login credentials when the shell is executed, so do you put your login credentials in the shell script or something?
linux shell
linux shell
asked Sep 25 '17 at 10:28
Tom
286
286
2
You generally don't give your credentials to the shell. When any login shell is executed you normally have already entered your login credentials - prompted eg. byssh
, a getty andlogin
or a display manager.
â Michaà  Politowski
Sep 25 '17 at 10:49
3
Question is in part answered by unix.stackexchange.com/questions/38175/â¦
â Kusalananda
Sep 25 '17 at 10:52
add a comment |Â
2
You generally don't give your credentials to the shell. When any login shell is executed you normally have already entered your login credentials - prompted eg. byssh
, a getty andlogin
or a display manager.
â Michaà  Politowski
Sep 25 '17 at 10:49
3
Question is in part answered by unix.stackexchange.com/questions/38175/â¦
â Kusalananda
Sep 25 '17 at 10:52
2
2
You generally don't give your credentials to the shell. When any login shell is executed you normally have already entered your login credentials - prompted eg. by
ssh
, a getty and login
or a display manager.â Michaà  Politowski
Sep 25 '17 at 10:49
You generally don't give your credentials to the shell. When any login shell is executed you normally have already entered your login credentials - prompted eg. by
ssh
, a getty and login
or a display manager.â Michaà  Politowski
Sep 25 '17 at 10:49
3
3
Question is in part answered by unix.stackexchange.com/questions/38175/â¦
â Kusalananda
Sep 25 '17 at 10:52
Question is in part answered by unix.stackexchange.com/questions/38175/â¦
â Kusalananda
Sep 25 '17 at 10:52
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
I can remember this confusion of my own the first time I started digging into the internals of a UNIX system. This is a much simplified explanation; understanding modern systems requires a lot of background knowledge that is too wide to fit into a StackExchange answer like this one.
The login credentials are requested by a privileged process called login
and you can see the executable with ls -l /bin/login
. (Source is also available, of course.) More information from man login
.
Among other things this process will use a number of library calls (via the PAM library, see man 7 pam
) to check your credentials, ensure that there are no time restrictions, that your home directory exists, etc. When all the criteria have been satisfied it will discard its privileges and start a copy of your preferred shell. Often (but not exclusively) this is defined as the last field in /etc/passwd
.
You can see your own password entry (that strangely, perhaps, does not include even an encrypted copy of your password) with the getent
command:
getent passwd "$USER"
roaima:x:1001:1001:Roaima:/home/roaima:/bin/bash
More information about the structure of this file can be found with man 5 passwd
.
Note that there is no hard and fast requirement for your shell to be /bin/bash
. It could be something entirely custom, as it runs only with your own account privileges.
Hopefully this will have explained that the shell itself knows nothing about your credentials. It is just a normal program (a complex one, perhaps) that when running in interactive mode reads from stdin and writes to stdout. The same program can be used in non-interactive mode to read and write to files, pipes, or sockets.
In principle there is little to stop to you writing your own shell that reads a line from its input, splits the words by whitespace, and then forks a child process to call execvpe()
and execute a program. (In practice there are a great many extra hurdles to overcome, such as not splitting quoted strings, actioning chdir
(cd
) directly in the parent, and signals.)
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
I can remember this confusion of my own the first time I started digging into the internals of a UNIX system. This is a much simplified explanation; understanding modern systems requires a lot of background knowledge that is too wide to fit into a StackExchange answer like this one.
The login credentials are requested by a privileged process called login
and you can see the executable with ls -l /bin/login
. (Source is also available, of course.) More information from man login
.
Among other things this process will use a number of library calls (via the PAM library, see man 7 pam
) to check your credentials, ensure that there are no time restrictions, that your home directory exists, etc. When all the criteria have been satisfied it will discard its privileges and start a copy of your preferred shell. Often (but not exclusively) this is defined as the last field in /etc/passwd
.
You can see your own password entry (that strangely, perhaps, does not include even an encrypted copy of your password) with the getent
command:
getent passwd "$USER"
roaima:x:1001:1001:Roaima:/home/roaima:/bin/bash
More information about the structure of this file can be found with man 5 passwd
.
Note that there is no hard and fast requirement for your shell to be /bin/bash
. It could be something entirely custom, as it runs only with your own account privileges.
Hopefully this will have explained that the shell itself knows nothing about your credentials. It is just a normal program (a complex one, perhaps) that when running in interactive mode reads from stdin and writes to stdout. The same program can be used in non-interactive mode to read and write to files, pipes, or sockets.
In principle there is little to stop to you writing your own shell that reads a line from its input, splits the words by whitespace, and then forks a child process to call execvpe()
and execute a program. (In practice there are a great many extra hurdles to overcome, such as not splitting quoted strings, actioning chdir
(cd
) directly in the parent, and signals.)
add a comment |Â
up vote
1
down vote
I can remember this confusion of my own the first time I started digging into the internals of a UNIX system. This is a much simplified explanation; understanding modern systems requires a lot of background knowledge that is too wide to fit into a StackExchange answer like this one.
The login credentials are requested by a privileged process called login
and you can see the executable with ls -l /bin/login
. (Source is also available, of course.) More information from man login
.
Among other things this process will use a number of library calls (via the PAM library, see man 7 pam
) to check your credentials, ensure that there are no time restrictions, that your home directory exists, etc. When all the criteria have been satisfied it will discard its privileges and start a copy of your preferred shell. Often (but not exclusively) this is defined as the last field in /etc/passwd
.
You can see your own password entry (that strangely, perhaps, does not include even an encrypted copy of your password) with the getent
command:
getent passwd "$USER"
roaima:x:1001:1001:Roaima:/home/roaima:/bin/bash
More information about the structure of this file can be found with man 5 passwd
.
Note that there is no hard and fast requirement for your shell to be /bin/bash
. It could be something entirely custom, as it runs only with your own account privileges.
Hopefully this will have explained that the shell itself knows nothing about your credentials. It is just a normal program (a complex one, perhaps) that when running in interactive mode reads from stdin and writes to stdout. The same program can be used in non-interactive mode to read and write to files, pipes, or sockets.
In principle there is little to stop to you writing your own shell that reads a line from its input, splits the words by whitespace, and then forks a child process to call execvpe()
and execute a program. (In practice there are a great many extra hurdles to overcome, such as not splitting quoted strings, actioning chdir
(cd
) directly in the parent, and signals.)
add a comment |Â
up vote
1
down vote
up vote
1
down vote
I can remember this confusion of my own the first time I started digging into the internals of a UNIX system. This is a much simplified explanation; understanding modern systems requires a lot of background knowledge that is too wide to fit into a StackExchange answer like this one.
The login credentials are requested by a privileged process called login
and you can see the executable with ls -l /bin/login
. (Source is also available, of course.) More information from man login
.
Among other things this process will use a number of library calls (via the PAM library, see man 7 pam
) to check your credentials, ensure that there are no time restrictions, that your home directory exists, etc. When all the criteria have been satisfied it will discard its privileges and start a copy of your preferred shell. Often (but not exclusively) this is defined as the last field in /etc/passwd
.
You can see your own password entry (that strangely, perhaps, does not include even an encrypted copy of your password) with the getent
command:
getent passwd "$USER"
roaima:x:1001:1001:Roaima:/home/roaima:/bin/bash
More information about the structure of this file can be found with man 5 passwd
.
Note that there is no hard and fast requirement for your shell to be /bin/bash
. It could be something entirely custom, as it runs only with your own account privileges.
Hopefully this will have explained that the shell itself knows nothing about your credentials. It is just a normal program (a complex one, perhaps) that when running in interactive mode reads from stdin and writes to stdout. The same program can be used in non-interactive mode to read and write to files, pipes, or sockets.
In principle there is little to stop to you writing your own shell that reads a line from its input, splits the words by whitespace, and then forks a child process to call execvpe()
and execute a program. (In practice there are a great many extra hurdles to overcome, such as not splitting quoted strings, actioning chdir
(cd
) directly in the parent, and signals.)
I can remember this confusion of my own the first time I started digging into the internals of a UNIX system. This is a much simplified explanation; understanding modern systems requires a lot of background knowledge that is too wide to fit into a StackExchange answer like this one.
The login credentials are requested by a privileged process called login
and you can see the executable with ls -l /bin/login
. (Source is also available, of course.) More information from man login
.
Among other things this process will use a number of library calls (via the PAM library, see man 7 pam
) to check your credentials, ensure that there are no time restrictions, that your home directory exists, etc. When all the criteria have been satisfied it will discard its privileges and start a copy of your preferred shell. Often (but not exclusively) this is defined as the last field in /etc/passwd
.
You can see your own password entry (that strangely, perhaps, does not include even an encrypted copy of your password) with the getent
command:
getent passwd "$USER"
roaima:x:1001:1001:Roaima:/home/roaima:/bin/bash
More information about the structure of this file can be found with man 5 passwd
.
Note that there is no hard and fast requirement for your shell to be /bin/bash
. It could be something entirely custom, as it runs only with your own account privileges.
Hopefully this will have explained that the shell itself knows nothing about your credentials. It is just a normal program (a complex one, perhaps) that when running in interactive mode reads from stdin and writes to stdout. The same program can be used in non-interactive mode to read and write to files, pipes, or sockets.
In principle there is little to stop to you writing your own shell that reads a line from its input, splits the words by whitespace, and then forks a child process to call execvpe()
and execute a program. (In practice there are a great many extra hurdles to overcome, such as not splitting quoted strings, actioning chdir
(cd
) directly in the parent, and signals.)
edited Sep 25 '17 at 14:23
answered Sep 25 '17 at 11:16
roaima
40.2k547110
40.2k547110
add a comment |Â
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%2f394293%2fhow-to-make-sense-of-non-interactive-login-shell%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
2
You generally don't give your credentials to the shell. When any login shell is executed you normally have already entered your login credentials - prompted eg. by
ssh
, a getty andlogin
or a display manager.â Michaà  Politowski
Sep 25 '17 at 10:49
3
Question is in part answered by unix.stackexchange.com/questions/38175/â¦
â Kusalananda
Sep 25 '17 at 10:52