Ubuntu 22.04 and dconf update

Posted by k1132810@reddit | linuxadmin | View on Reddit | 3 comments

Hey folks, hope this is an easy one. I've got some settings configured in /etc/dconf/local.d/ and those same settings locked down in ./locks. Now for a while, I noticed that the locks were working on one device in our environment, but not another, even though both were using the exact same files. What appeared to be the issue was file permissions. The 'local' file that sits in the same directory as local.d had 640 permissions while on the device that was working it had 644 permissions. Makes sense, if the user logging in can't read the file that guides everything to the settings/locks, why would it work? Easy fix, yeah? sudo chmod 644 local. But then any time after that, if you run dconf update, it reverts the file permissions. If I change them and leave them, the locks perist between logs and reboots and all that, which is great. But I have no idea why updating the dconf database would mess with file permissions. Any thoughts?

[-]

mgedmin@reddit

What is your umask when you use sudo? You can check with sudo sh -c umask. Normally it should be something like 022. If you get 027, that would explain why all the read permissions are getting stripped from other.

k1132810@reddit (OP)

Whoa, that was exactly it, thank you. It is 0027. I have to assume that's not the default setting. We did previously run a CIS benchmark script, which I guess I could check over and see if it changes anything related to this. Would you happen to know the command that would change it back?

umask is part of the process state, like environment variables. The default is set by /etc/login.defs, I think? The pam_umask manual page shows several alternative configuration locations (including the GECOS field in /etc/passwd, whoa, didn't know about that possibility!). Of course things like your .profile/.bashrc could override the umask too!

(I had the hardest time trying to relax the umask for all the users to 002 back when I was setting up a local Subversion repository with separate ssh accounts for each developer. I think I ended up having to create a svnserve wrapper script that overrode the umask and exec'd the real one. I don't miss those days.)