You can replace nullok_secure with nullok in /etc/pam.d/common-auth. You may also need to adjust values in /etc/pam.d/sshd if you have some specific overrides.
You should have something like this in your common-auth file:
auth [success=1 default=ignore] pam_unix.so nullok
The terminal emulator will send a Window Change signal (SIGWINCH) to the shell that was started along with the terminal emulator. The shell is supposed to pass it on to its children - but when you've transitioned to another user account (using su or otherwise), it won't be able to signal that shell because it's running as a different user. So the su'd shell ...
Even if you got sudo onto your system (easy), it would not help. It needs to be setuid-root to work. And you can't set that up, without root access.
If running the commands without sudo is not working, then it is because the Dockerfile has USER line. If you edit the Dockerfile, to put the apt-get (or the commands to install apt-get) before this line, then ...
This is what I have in /etc/pam.d/login:
Unless you modified /etc/pam.d/su-l to include this file, this is file is not relevant as su -l only mimics login by switching the home directory and resetting some environment variables.
The default /etc/pam.d/su-l (which is used by su -l on Arch Linux) should look like this:
auth sufficient ...
I entered it manually, after the other auth commands, but - it doesn't work.
The order of the items in the stack is important as PAM proceeds through them in sequence.
Citing (from man pam.conf) the relevant explanation for what the sufficient control flag does:
if such a module succeeds and no prior required module has failed the PAM framework returns ...
I've been using sudo's built in user assumption tool,
dev is the sudoer user name, or
dev is the sudeoer group name (sudo configuration calls this %dev)
and tomcat is the destination user
/!\ Note, always validate sudo's configuration files with visudo before writing, or always edit sudo's configuration files with visudo. An invalid sudo ...