Bug 7378 - Session creation may fail when home directories are on autofs mount
Summary: Session creation may fail when home directories are on autofs mount
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Agent (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Bugzilla mail exporter
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-10 00:25 CEST by Aaron Sowry
Modified: 2022-02-23 11:25 CET (History)
1 user (show)

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Aaron Sowry cendio 2019-09-10 00:25:55 CEST 
The issue occurs when make_homedir is set to true, and the user's home directory exists, but is currently not "visible" in the autofs mount due to no prior access.

When make_homedir is true, ThinLinc will always attempt to create the home directory during session startup. Normally, if this directory already exists, then we get EEXIST and carry on. But in the autofs case, if the directory is not "visible" yet, we get EPERM back instead. This is fatal and session creation fails.

Perhaps we can stat() the directory before trying to create it, in order to trigger the mount.

There is a discussion of this behaviour in Python with regards to autofs here: https://bugs.python.org/issue14702

Cendio bugs 2358 and 4621 are also related.
Comment 1 Pierre Ossman cendio 2019-09-10 12:44:03 CEST 
So this has changed wildly over the years.

Before bug 2358 this feature was disabled by default and so didn't affect most users. Rationale is unfortunately hidden in kom somewhere, so it is unknown why we considered this a better default. One guess is that many of the customers back then were using ThinLinc as a Windows front end without centralised home directories. Unsure why pam_mkhomedir wasn't a better idea.

Then on bug 4621 we changed the logic a bit to deal with /home that root wasn't allowed to access. As part of that restructuring we added compatibility code to deal with automount on Solaris. It also had the side effect of improving compatibility with automount on Linux as well. So at that point we didn't have any issue with autofs as mentioned on this bug.

But then on bug 3614 we removed support for Solaris and so the workaround for automount also went away as we weren't aware that it also had a purpose on Linux.
Note You need to log in before you can comment on or make changes to this bug.