SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The need to create the .asc files of the packages is to customize the distro, each package would have its signature and later an iso image would be created with all the packages.
It is fully possible to add custom packages to a customized .iso without any corresponding .asc files. The installation scripts calls installpkg in the initrd of the .iso and installpkg does not verify packages from any .asc files.
However, if your intention is to clone your own distro starting off with Slackware and share that distro with others it might be a good idea to have .asc files for every shipped package and to share your own public gpg key.
I just tried it from a root XTerm opened with su, which is my usual way of getting to root.
Code:
# login
bigboy login: hazel
Password:
Linux 5.15.145.
hazel@bigboy.localdomain:~
Seems to work. Slackware-15, util-linux-2.37.4, bash 5.1.4.
You bash is little older than Slackware-15. Current-before-15.0 upgraded to bash-5.1.008 May 5 2021 and the 15.0 was released Feb 2 2022 with bash-5.1.016. It shouldn't matter, but you may have other older packages.
I wonder if your /bin/login is really from util-linux and not from shadow.
I guess you have not set up any signal handlers in your bash config files. Like this:
Code:
kaukasoi@acer:~ $ trap "" SIGHUP
kaukasoi@acer:~ $ su -
Password:
root@acer:~# login
acer login: kaukasoi
Password:
Last login: Tue May 21 09:06:02 on pts/4
Slackware 15.0 / Linux 6.9.1
kaukasoi@acer:~ $
The move of /bin/login from shadow to util-linux happened here:
Code:
Mon May 18 19:17:21 UTC 2020
Greetings! After three months in /testing, the PAM merge into the main tree
is now complete...
...
a/shadow-4.8.1-x86_64-7.txz: Rebuilt.
Rebuilt to add PAM support.
a/util-linux-2.35.1-x86_64-6.txz: Rebuilt.
Rebuilt to add PAM support.
Last edited by Petri Kaukasoina; 05-21-2024 at 01:37 AM.
No, it's not a bug but a feature. Try to execute command 'login' as root from a terminal window.
Code:
$ su -
Password:
# login
<bash gets killed>
/bin/login (of util-linux) uses system call vhangup() to kill all other processes on the current tty, so the shell gets killed. Any version of any shell.
In slackware-14.2 there was the old /bin/login from shadow. It didn't kill anything, so the previous user of the tty could run a process reading everything, passwords included, of what the next user types. Or could write anything to the next user's screen.
In that case it does not depend on that script at all, irrelevant if only one or more users were created. And also the version of bash doesn't really matter.
I just tried it from a root XTerm opened with su, which is my usual way of getting to root.
Seems to work.
OK, I found it. If you start the root xterm like this:
Code:
xterm -e su -
Then /bin/login won't kill the window.
I am not sure why, but there is a difference: there is no bash process between xterm and su to be killed.
Another difference: 'ps as --signames' shows for the su command:
Code:
UID PID PENDING BLOCKED IGNORED CAUGHT STAT TTY TIME COMMAND
0 1479 - fffffffe7ffb9eff BUS,KILL,SEGV,USR2,CHLD+ ABRT,FPE,KILL,USR1,SEGV+ Ss pts/7 0:00 su -
But when there is a bash process between xterm and su:
Code:
UID PID PENDING BLOCKED IGNORED CAUGHT STAT TTY TIME COMMAND
0 1624 - fffffffe7ffb9eff - ABRT,FPE,KILL,USR1,SEGV+ S pts/6 0:00 su -
I would have thought that vhangup() would have killed the 'su -' process and the root shell which shows as '-su', because they were using the same tty. But it didn't. Only the bash shell between xterm and su was killed.
Last edited by Petri Kaukasoina; 05-21-2024 at 06:06 AM.
$ xterm -e su -
(2nd terminal opens)
Password:
root@bigboy:~# login
bigboy login: hazel
Password:
Linux 5.15.145.
hazel@bigboy.localdomain:~
$
Quote:
Originally Posted by Petri Kaukasoina
OK, I found it. If you start the root xterm like this:
Code:
xterm -e su -
Then /bin/login won't kill the window.
But that's the point isn't it? It's supposed to kill the window (that's what the OP was complaining about) but on my machine it doesn't do that, neither with su or su -.
I edited my post #22 afterwards, added a possible explanation: there is a bash process to be killed between xterm and su on the same tty, while there is none when you do it your way.
Last edited by Petri Kaukasoina; 05-21-2024 at 06:02 AM.
No, it's not a bug but a feature. Try to execute command 'login' as root from a terminal window.
Code:
$ su -
Password:
# login
<bash gets killed>
/bin/login (of util-linux) uses system call vhangup() to kill all other processes on the current tty, so the shell gets killed. Any version of any shell.
In slackware-14.2 there was the old /bin/login from shadow. It didn't kill anything, so the previous user of the tty could run a process reading everything, passwords included, of what the next user types. Or could write anything to the next user's screen.
You said it's not a bug or feature, but when running this same mass user creation script on Debian and Linux Mint, even when logged in as root, I immediately execute:
Code:
# login usuario1
Password:
I can log in with the user normally without bash giving this crash because they are the same versions of bash which, if I'm not mistaken, is a child process of the real terminal
OK, I found it. If you start the root xterm like this:
Code:
xterm -e su -
Then /bin/login won't kill the window.
I am not sure why, but there is a difference: there is no bash process between xterm and su to be killed.
Another difference: 'ps as --signames' shows for the su command:
Code:
UID PID PENDING BLOCKED IGNORED CAUGHT STAT TTY TIME COMMAND
0 1479 - fffffffe7ffb9eff BUS,KILL,SEGV,USR2,CHLD+ ABRT,FPE,KILL,USR1,SEGV+ Ss pts/7 0:00 su -
But when there is a bash process between xterm and su:
Code:
UID PID PENDING BLOCKED IGNORED CAUGHT STAT TTY TIME COMMAND
0 1624 - fffffffe7ffb9eff - ABRT,FPE,KILL,USR1,SEGV+ S pts/6 0:00 su -
I would have thought that vhangup() would have killed the 'su -' process and the root shell which shows as '-su', because they were using the same tty. But it didn't. Only the bash shell between xterm and su was killed.
probably process group related, login can (or will) only kill the process group. But need to check it.
You said it's not a bug or feature, but when running this same mass user creation script on Debian and Linux Mint, even when logged in as root, I immediately execute:
Code:
# login usuario1
Password:
I can log in with the user normally without bash giving this crash because they are the same versions of bash which, if I'm not mistaken, is a child process of the real terminal
I am not familiar with Debian or Linux Mint. But this Debian man page for login(1) says 'shadow-utils 4.11.1', so I guess their login doesn't try to remove any possible password sniffing processes on the tty.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
