During the work on Bug #49060 it was discovered, that if an ImportError occurs in a Python script, the PAM stack will interpret it as "no access allowed". If is is a "required" directive in /etc/pam.d/common-session, it will lead to a non-accessible system. The Python3 migration raises the dangers of such exceptions, so marking all Python scripts in the PAM stack as "optional" instead of "required" raises the robustness of the system.
Most pam scripts are already optional. The one which is by default required currently is univention-mount-homedir. Workaround currently is: ucr set homedir/mount/required=false
IMHO the scripts that we deliver to the customer should be free of "ImportError" exceptions or anything like that. You can always break the system from within, we need to make sure that it works well by default.
We should also lower the risk posed by non-default situations (like interrupted updates) by making the system as resilient as possible.
(In reply to Daniel Tröder from comment #3) > We should also lower the risk posed by non-default situations (like > interrupted updates) by making the system as resilient as possible. But it might be better to be more transparent in this situation? If this really fails there is a deeper error. If we ignore this, the functionality of e.g. univention-mount-homedir is not executed and nobody notices it until the log files are scanned. The other view is ofc. that if there are issues in the scripts which can be triggered by regular users, then DoS is possible. That's why you flagged it as security issue?
(In reply to Florian Best from comment #4) > (In reply to Daniel Tröder from comment #3) > > We should also lower the risk posed by non-default situations (like > > interrupted updates) by making the system as resilient as possible. > But it might be better to be more transparent in this situation? > If this really fails there is a deeper error. > If we ignore this, the functionality of e.g. univention-mount-homedir is not > executed and nobody notices it until the log files are scanned. That is why I had added a "syslog()" line to the ImportError handling. Maybe we could do that again, but after logging, reraise it? This way the problem would not be hidden, and it would be logged. > The other view is ofc. that if there are issues in the scripts which can be > triggered by regular users, then DoS is possible. That's why you flagged it > as security issue? I was merely thinking about "reliability" as one of the dimensions of "security". The incident would in this case (that actually happend during the work on Bug #49060) not be triggered by a common user, but by an incomplete update started by an administrator.
This issue has been filed against UCS 4.4. UCS 4.4 is out of general maintenance and components may have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer versions, please use "Clone this bug" or reopen this issue. In this case please provide detailed information on how this issue is affecting you.