Univention Bugzilla – Bug 33241
UMC runs with umask 0077
Last modified: 2022-07-29 14:35:54 CEST
In one test environment the update to UCS 3.2 failed running 35univention-management-console-module-appcenter.inst with the following error message: ============================================================================ Waiting for activation of the extension object univention-app:.......................................................ERROR: Master did not mark the extension object active within 180 seconds. ERROR ucs_registerLDAPExtension: registraton of /usr/share/univention-management-console-module-appcenter/univention-app.schema failed. ============================================================================ The listener.log shows that the listener (or one of the modules) is not able to open base.conf: ============================================================================ root@ucs-master:~# /usr/sbin/univention-directory-listener -F \ -b dc=samba4,dc=ucs,dc=demo \ -m /usr/lib/univention-directory-listener/system \ -c /var/lib/univention-directory-listener \ -d 4 -x -ZZ -D cn=admin,dc=samba4,dc=ucs,dc=demo -y /etc/ldap.secret 11.11.13 13:00:01.586 DEBUG_INIT 11.11.13 13:00:01.587 CONFIG ( ERROR ) : Error on opening "/etc/univention/base.conf" 11.11.13 13:00:01.587 CONFIG ( ERROR ) : Error on opening "/etc/univention/base.conf" 11.11.13 13:00:01.588 CONFIG ( ERROR ) : Error on opening "/etc/univention/base.conf" 11.11.13 13:00:01.588 CONFIG ( ERROR ) : Error on opening "/etc/univention/base.conf" Speicherzugriffsfehler =============================================================================
strace shows: open("/etc/univention/base.conf", O_RDONLY) = -1 EACCES (Permission denied) The permissions of base.conf are too strict, maybe the umask of some process is wrong? root@ucs-master:~# ls -l /etc/univention/base.conf -rw------- 1 root root 28590 11. Nov 12:58 /etc/univention/base.conf
Perhaps related: The UMC-Server runs with umask 0077, see Bug #33157 for a similar issue.
mhm, I changed an UCR variable using the UMC UCR module during the update progress (started also in UMC).
We should re-check the umask handling of UMC.
(In reply to Ingo Steuwer from comment #3) > mhm, I changed an UCR variable using the UMC UCR module during the update > progress (started also in UMC). Yes, this is possible. In which way do you think that this is a problem?
(In reply to Alexander Kläser from comment #5) > (In reply to Ingo Steuwer from comment #3) > > mhm, I changed an UCR variable using the UMC UCR module during the update > > progress (started also in UMC). > > Yes, this is possible. In which way do you think that this is a problem? My guess is that the change triggered the wrong file permissions of /etc/univention/base.conf This might already be fixed, as the machine hadn't the latest UCS 3.1 Erratas.
We had a similar problem: Bug #33157.
I can reproduce the error from Comment 1 with Comment 6 and some preparation (bad timing?): Log into UMC Open UCR module Open a variable's dialog (do not save yet) mv /etc/univention/base* ~ Save the variable ls -l /etc/univention/base.conf -rw------- root root base.conf But this seems unlikely to happen in the real world.
Explicitly setting umask to 0077 may cause problems in some situations. Question is: Why was it done this way in the first place? Not creating a world readable secret file by accident seems to be a good idea. I am not so sure whether we can easily switch to 0022 in an errata update. Some functions may rely on the fact that only root may read the files created. (/etc/$service.secret? /var/cache/univention-management-console/acls/?). 0022 will certainly not break anything, but maybe expose some files. Maybe we can protect certain directories manually, e.g. /var/tmp/univention-management-console-frontend/ (where all the upload goes).
(In reply to Dirk Wiesenthal from comment #9) > Explicitly setting umask to 0077 may cause problems in some situations. In general daemons are advised to set umask(0), just to guarantee deterministic behavior. See <http://www-theorie.physik.unizh.ch/~dpotter/howto/daemonize>. Here's some more background: <http://stackoverflow.com/questions/7141793/file-creation-mode-mask> > Question is: Why was it done this way in the first place? Not creating a > world readable secret file by accident seems to be a good idea. See Bug #25162 AKA r29782.
umask was set for Bug #25162 If we fix the issues mentioned there, maybe we can change the umask back to 0? Issues were: * some files in /var/run/ (e.g. umc-server.pid.lock) * acl file * log files (presumably already resolved, but should be double checked) As I said before, check the uploaded files. Maybe /var/cache/u-m-c, too (out of paranoia. Currently used for App Center ini files and acls files, where the App Center is not ciritical and the acls may be handled separately). Searching for (writable) file handles in the code is difficult. One should grep at least for "with open" ("open" would be better but yields a lot of udm noise) and "shutil" and "os" (for os.rename, os.mkdir, etc)
(In reply to Dirk Wiesenthal from comment #11) > Searching for (writable) file handles in the code is difficult. One should > grep at least for "with open" ("open" would be better but yields a lot of > udm noise) and "shutil" and "os" (for os.rename, os.mkdir, etc) open([^)], fd, fn, file
The profile script of system setup should be protected
There are two options: 1. Fix it now, fix it forever: Change umask from 0077 to 0000 or 0022. This would solve all problems regarding file permissions being too restrictive. All spawned processes would have reasonable defaults for new files. Problem: Backward compatibility; we will have problems finding all files that may require rw-------. We will not see any problems (everything that worked before will work afterwards, i.e. all existent tests will most probably run successfully, they are more or less useless here), we really need to be mindful with every file created in any directory by any UMC module: Is is okay, that this file is world readable?! 2. Fix it now, be backwards compatible: This could be done by adding UCR variables for the umask. Set it in postinst to 0077 for existing umc-server (upgrade) and to 0022 for new installations. Problem: Same permission problems as in (1), plus: We will have from now on two divergent UMC versions with security problems in one group and not services refusing to start in the other. And at some point all Univention Developers will have their systems reinstalled and only test with 0022 while there are many 0077 systems out there. This bug really needs to be fixed, we cannot leave it this way. univention-run-join-scripts runs with a different umask as UMC/Join. univention-add-app runs with different umask as UMC/App Center. But changing it now is too dangerous. We need the whole Product Tests, we need some time to find files that need proper protection. The most important things seem to be resolved by workarounds by now. Let's hope that no new problems arise during UCS 3.2 lifetime and wait for the next major release.
Removed the umask in univention-management-console-server scripts. UCR problem is gone. I have looked at some files created by UMC and the sensitive ones (ACLs, profile, uploads, socket, even logs) are all protected. RESOLVED for now.
The Jenkins check permissions check fails since a few days. Maybe this change is the cause: ***Searching for files and directories with write permissions for other: drwxrwxrwx 2 root root 40 Okt 18 00:53 /run/univention-management-console See http://jenkins.knut.univention.de:8080/job/UCS-4.0/job/UCS-4.0-0/job/Autotest%20MultiEnv/34/SambaVersion=s4,Systemrolle=master/testReport/junit/00_base/25check-permissions/test/
ls -l /var/www/univention-directory-reports/univention-directory-reports-970utE.csv -rw-r--r-- 1 www-data www-data 934 Oct 20 13:15 /var/www/univention-directory-reports/univention-directory-reports-970utE.csv ls -l /var/log/univention/directory-*cleanup*log -rw-r--r-- 1 root root 0 Aug 27 06:00 /var/log/univention/directory-reports-cleanup.log
As discussed: Too many possible side effects regarding security. Better fix modules that are buggy with this custom umask separately. Fixes reverted.
I have added Bug#36271 and Bug#36270 for test cases regarding the two issues related to this bug: Files created during UCR updates and files created during join.
OK, commits have been reverted.
UCS 4.0-0 has been released: http://docs.univention.de/release-notes-4.0-0-en.html http://docs.univention.de/release-notes-4.0-0-de.html If this error occurs again, please use "Clone This Bug".