You are not logged in.
Tonight, I tested the slim "suites/unstable" branch, and confirmed that the two patches did fix the problems they were supposed to fix. I also confirmed that auto-login + bad user name still crashes in the "unstable" branch, so it's still a problem.
I also have some feedback about the patches, so I'll post that in a separate comment.
And I have an explanation for the autologin + bad user name crash from examining the daedalus slim source code. I need to confirm that the explanation is still the same in "unstable" slim. Then I'll write a separate comment.
* My test notes
* Test the slim compiled from git.devuan.org
* Details
- https://git.devuan.org/devuan/slim/
- branch: suites/unstable (default branch)
* Test cases
+ slim - auto_login (yes) - untitled window?
+ Confirmed as fixed: No "untitled window" appears.
+ 2nd confirmation: In App::Login(), commenting out the new code provided by the patch "Patch-to-fix-auto_login-regression-introduced-in-1.4.patch" causes the Untitled Window to appear, confirming that this patched code is what fixed the problem.
if ( autologin )
{
//LoginPanel->ClosePanel();
}
! slim - auto_login (yes) + default_user (bad name). What will the error handling do?
! Ans: No login screen. This is the same crash reported as new in daedalus slim and excalibur slim, and still occurs on this "suites/unstable" slim.
- "ps -ef | grep slim" doesn't show slim running.
+ slim - auto_login (yes) + default_user (no name). What will the error handling do?
+ Login screen is displayed normally.
+ No regression here.
+ Monitorless auto_login (yes) - Will slim crash?
+ Confirmed as fixed: Unplug the VGA cable, power on the PC, wait for the auto login duration, plug in the VGA cable -> Xfce desktop is shown. "ps -ef | grep slim" shows that slim is running.
+ 2nd confirmation: Restoring the original code causes slim to crash again, confirming that "Set-default-resolution-if-monitor-absent.patch" has fixed this crash.
result.width = crtc_info->width;
result.height = crtc_info->height;* My setup/compile notes, in case I (or someone else) needs this
* Download commands
mkdir slimunstable
cd slimunstable
git clone https://git.devuan.org/devuan/slim/
cd slim
git status
- The default branch is suites/unstable. I assume this is the correct branch?
* Setup/compile commands
dpkg-source --before-build .
dpkg-checkbuilddeps
- This will tell you which dependencies are not found, and you'll have to install them.
debian/rules
- This creates a directory obj-x86_64-linux-gnu with a Makefile.
cd obj-x86_64-linux-gnu
make -j<number of parallel jobs>
- The executable "slim" is created in this directory.
* Copying slim to /usr/bin
- Do this just once: Make a backup of the original slim.
sudo cp -ax /usr/bin/slim /usr/bin/slim.orig_installed
- Copy the compiled slim.
sudo cp -f slim /usr/binOffline
* Feedback: Patch-to-fix-auto_login-regression-introduced-in-1.4.patch
- This patch addresses an issue I had: when should App::Login() close the child "Untitled" window. The patch closes it as late as possible, just before Su.Login(). From my debugging, slim waits inside Su.Login() during the desktop session. So if anything went wrong earlier, the child window is still available.
- Otherwise, no suggestions, etc that I can think of.
* Feedback: Set-default-resolution-if-monitor-absent.patch
The current patch hardcodes the 1024x768 resolution when there's no monitor.
result.width = (crtc_info->width == 0 ? 1024 : crtc_info->width);
result.height = (crtc_info->height == 0 ? 768 : crtc_info->height);But I noticed that in the earlier parts of Panel::GetPrimaryViewport(), when something goes wrong, the code returns the "fallback" width and height to the caller. This "fallback" is computed from the X Window's Display's width and height. I've confirmed that this is where the 1024x768 comes from in my tests.
So a proposed solution is that when the monitor width and height are 0, use the fallback width/height. And if anything goes wrong with the fallback width/height, THEN hardcode to 1024x768.
result.width = (crtc_info->width > 0 ? crtc_info->width : fallback.width > 0 ? fallback.width : 1024);
result.height = (crtc_info->height > 0 ? crtc_info->height : fallback.height > 0 ? fallback.height : 768);Last edited by Eeqmcsq (Yesterday 08:16:54)
Offline
For the slim crash caused by auto_login (yes) + default_user (bad name), I've confirmed that the cause is the same in both Daedalus slim and "unstable" slim.
Slim did not actually crash. Instead, it intentionally exit() the app because it caught a PAM exception that it thought was too serious to continue.
* Where the exit() is occurring
The exit() occurs in App::Login() when the code tries to open a PAM session. Here's a condensed version of the code:
try{
pam.open_session();
}
catch(PAM::Cred_Exception& e){
/* Credentials couldn't be established */
return;
}
catch(PAM::Exception& e){
exit(ERR_EXIT);
}There are two error handling paths. The "Cred_Exception" path is considered "non-fatal" and returns control to the caller. The "Exception" path is considered "fatal" and will exit the app.
* Initial explanation
The Exception is thrown from Authenticator::open_session. Here's a condensed version:
void Authenticator::open_session(void)
{
switch ((last_result=pam_setcred(pam_handle, PAM_ESTABLISH_CRED)))
{
default:
case PAM_CRED_ERR:
case PAM_CRED_UNAVAIL:
throw Exception(pam_handle, "pam_setcred()", last_result);
case PAM_ACCT_EXPIRED:
case PAM_PERM_DENIED:
case PAM_CRED_EXPIRED:
case PAM_USER_UNKNOWN:
throw Cred_Exception(pam_handle, "pam_setcred()", last_result);
case PAM_SUCCESS:
break;
}
switch ((last_result=pam_open_session(pam_handle, 0)))
{
default:
throw Exception(pam_handle, "pam_open_session()", last_result);
case PAM_SUCCESS:
break;
}
return;
}The code makes a call to pam_setcred() and pam_open_session(). For the pam_setcred() error handling, the code treats some errors as fatal, while others are non-fatal, including PAM_USER_UNKNOWN, which is the situation we're testing. Looking at the pam_setcred() man page, PAM_USER_UNKNOWN is a possible return value.
For pam_open_session(), all errors are fatal errors. Look at the pam_open_session() man page, there are only a few errors that can be returned.
But even though the code looks good, what happens is that for a bad user name, pam_setcred() does NOT return PAM_USER_UNKNOWN, or any other error code! Instead, pam_open_session() DOES return PAM_USER_UNKNOWN, even though that's not a documented return code. PAM_USER_UNKNOWN is treated as a fatal exception, causing slim to exit.
* Root cause
During my debugging, I found out that a manual login using the slim GUI doesn't have these problems because the code doesn't even try to go through the App::Login() code. Instead the code validates the user/password FIRST, and THEN goes into the login process. So I wondered why the autologin doesn't try to validate the user name first.
I just discovered that the slim's autologin code DID try to validate the user name first. There's even a comment in the Auth_Exception error handling that describes the possibility of a bad user name. Here's the condensed code:
if (autologin)
{
try {
pam.check_acct();
Login(true);
}
catch(PAM::Auth_Exception& e){
// The default user is invalid
}
}So the entire mess with Authenticator::open_session() could have been avoided. So why didn't Authenticator::check_acct() throw an Auth_Exception that would have skipped the auto login attempt on a bad user name?
void Authenticator::check_acct(void)
{
switch((last_result=pam_acct_mgmt(pam_handle, PAM_SILENT)))
{
case PAM_ACCT_EXPIRED:
case PAM_USER_UNKNOWN:
case PAM_PERM_DENIED:
throw Auth_Exception(pam_handle, "pam_acct_mgmt()", last_result);
default:
case PAM_NEW_AUTHTOK_REQD:
case PAM_AUTH_ERR:
case PAM_SUCCESS:
break;
}
}pam_acct_mgmt() is supposed to check if a user account is valid. And this function IS handling the error code PAM_USER_UNKNOWN and would have thrown an Auth_Exception.
But according to my tests, pam_acct_mgmt() is actually returning error code 7 - PAM_AUTH_ERR (Authentication failure), which this code treats as "OK to proceed", which allows the autologin to proceed. I have no idea why pam_acct_mgmt() would return an authentication failure for a bad user name. Maybe a bug in the pam library?
* Possible fix
The simplest fix from within slim is to move "case PAM_AUTH_ERR:" to the first section so it throws an Auth_Exception and tells the autologin code to skip the autologin and proceed with the login GUI. I've confirmed that this change solves the autologin + bad user name crash in both Daedalus slim and "unstable" slim.
Of course, I don't know anything about PAM or what other situations could trigger a PAM_AUTH_ERR, so I don't know what side effects could occur with this change.
Offline
It just occurred to me that all of the problems that I saw with auto_login (yes) + default_user (bad name) is due to the PAM library's error handling not behaving as described in the man pages, and not due to any coding problems in slim. Is PAM known to be problematic? Perhaps a better long term solution is for someone to go into PAM to find out what's actually going on with its error handling?
Offline
@Eeqmcsq
Thanks for mentioning Excalibur + slim display manager.
I had upgrade from Daedalus to Excalibur.
So my stack was Excalibur + xfce + lightdm
But it was only booting to the command line, and I had to run startx manually every time.
I've installed slim and chosen that as the display manager. Now on boot, startx does work automatically and I get to the slim logon.
:-)
Online