I’ve moved a lot of my files into a new user account (consolidating it to one account on one computer).
Because I used Dolphin in Super User Mode that meant using chown to change the owner and group.
To make it complete, I used chmod -R u=rwX,g=rX,o-rwx on the /home/username directory.
Suddenly, packagekit or polkit starts throwing authentication errors whenever Software Updates in KDE’s systray tries to do what it is designed to do.
How can I fix this?
It will be very tricky to solve this, I think your best bet is to go back using a backup.
One other approach is too look at the authentication errors, try to understand what is wrong and fix it. It could be that just moving the files and not the chmod is causing these problems.
PackageKit has always brought problems, which is why so many experienced openSUSE users routinely delete or never load it, and use the reliable YaST Online Update or update manually.
If you want to use PK, my suggestion is to use YaST > Software Management to search for “packagekit” and uninstall everything found with the exception of the following three packages:
libpackagekit-glib2-18
libpackagekitqt5-0
typelib-1_0-PackageKitGlib-1_0
Afterwards restart YasT > Software Management, search for “packagekit”again and install
pk-update-icon
this should automatically select all the other required PackageKit packages for reinstallation. Hopefully that will rewrite the polkit configuration with sensible values.
As a PK-phobic I have not tested this, but I do not think that it will do any harm. It might be necessary to restart polkit after deleting and reinstalling.
I never moved dot files or dot folders. None of the files I moved could affect authentication.
I did read that chmod could remove the uid, gid or acl settings. Maybe that’s what happened to certain dot files and now polkit is complaining about it? Not that the error messages are useful. Nor is there any dot file that seems like it’s part of some authentication process.
I already tried a more extreme solution: I reinstalled opensuse 42.3 (I was moving everything to a new hard drive and only the root partition was still on the older hard drive). This didn’t work.
I can understand why packagekit brings problems when even a reinstall doesn’t fix the problem. This means that the authentication is somehow connected to \home\username (which just seems like an awful design decision). More specifically, it seems connected to owner, user group and permissions (as the problems occurred afterwards).
What is reported if you run pkcon (PackageKit CLI) from a user terminal?
pkcon refresh
Any errors?
It gives:
Refreshing cache =========================]
Waiting for authentication
and then an “Authentication Required” dialogue pops up. When you click for details, it just gives you pid numbers.
After giving it the root password, I get this:
Refreshing cache =========================]
Waiting for authentication =========================]
Starting =========================]
Refreshing software list =========================]
Finished =========================]
Ok, and what does the following report?
loginctl list-sessions
and
pkaction -av org.freedesktop.packagekit.system-update
The following:
SESSION UID USER SEAT
2 1000 myusername seat0
1 481 sddm seat0
The following:
org.freedesktop.packagekit.system-update:
description: Update software
message: Authentication is required to update software
vendor: The PackageKit Project
vendor_url: http://www.packagekit.org/
icon: package-x-generic
implicit any: auth_admin
implicit inactive: auth_admin
implicit active: yes
The polkit privileges check out as expected ie active user should be able to run ‘pkcon refresh’ (or ‘pkcon update’) without authentication. I assume no overrides in /etc/polkit-default-privs.local?
Ok, and this should also report user 1000 is active…
loginctl show-session $XDG_SESSION_ID
I’m not sure what else could be wrong here… :\
Perhaps this too…
env|grep XDG
None.
It seems to:
Id=4
User=1000
Name=myusername
Timestamp=Mon 2018-02-12 11:29:00 CET
TimestampMonotonic=1829777867
VTNr=7
Seat=seat0
Display=:0
Remote=no
Service=sddm
Desktop=KDE
Scope=session-4.scope
Leader=6111
Audit=4
Type=x11
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
I’m still baffled how chmod and chown can cause this problem. And why a complete reinstall didn’t fix it. I will create a new account to see whether the problem occurs then.
It returns:
XDG_VTNR=7
XDG_SESSION_ID=4
XDG_SESSION_CLASS=user
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_CONFIG_DIRS=/etc/xdg
XDG_SESSION_TYPE=x11
XDG_SEAT=seat0
XDG_SESSION_DESKTOP=KDE
XDG_DATA_DIRS=/usr/share
XDG_RUNTIME_DIR=/run/user/1000
XDG_CURRENT_DESKTOP=KDE
Huh. Created a test account and after logging in, it too popped up the authentication dialogue for the software updates. So it seems I committed a post hoc fallacy by associating it with chmod and chown.
Did you change the system security level maybe?
That governs whether the root password is needed or not.
grep SECURITY /etc/sysconfig/security
You mean “Security Center and Hardening”? I did create a new account, put my files into it, ran chmod and chown — and went looking for a way to make the system create files and directories with rwXr-X— permissions. I did set the file permissions in “Security Center and Hardening” to secure.
PERMISSION_SECURITY="secure local"
# PERMISSION_SECURITY. If PERMISSION_SECURITY contains 'secure' or
And indeed, switching the file permissions back to “easy” means that software updates can run without requiring a root password. SOLVED. YEAH.
I didn’t notice any difference with the actual file permissions (of newly created files and directories) so I forgot I changed it. And it does say file permissions. They should update the help dialogue to “does **** all to your file permissions, but ****s with software updates”.
EDIT: At least the profanity filter work like it’s supposed to.:sarcastic:
EDIT: Thanks for the help everyone who replied.
Yes, “secure” permissions require the root password to install updates, while “easy” allows a locally logged in user to do that without a password.
If you do want to have secure permissions and still being able to install updates without the root password, that can be overridden in the “local” permissions.
Feel free to ask for further instructions in that case.
But “secure” will have other implications too, like not being able to mount removable devices (like an USB stick) as user.
I didn’t notice any difference with the actual file permissions (of newly created files and directories) so I forgot I changed it. And it does say file permissions. They should update the help dialogue to “does **** all to your file permissions, but ****s with software updates”.
Yes, that’s how it is since years.
You might want to file a bug report (bugzilla.opensuse.org, same username/password as here) about this.
But I don’t think they will change it for the released Leap 42.3… 
PS: that option is not supposed to change file permissions in the user’s home.
It changes file permissions of the system-wide installed files and also the polkit rules.
But that’s probably not clear enough by the description…
You can change the permissions of newly created user files in /etc/login.defs (option UMASK).
Probably in YaST as well, but I forgot where exactly.
Yeah, it makes sense to call it file permissions because everything is a file on linux/unix, but it’s not intuitive.
Done. About the help description. (I hope I did it right.)
I noticed nothing changed after setting it.
Nope, not clear at all.
I did search for a way to change UMASK, but I immediately found warnings that it was set by PAM. Digging deep into unix file permissions was fun, but also illuminating because it doesn’t do what you intuitively think it does. UMASK uses some interesting logic (first negation then logical AND), but can also be changed for each Konsole session. Anyway, researching file permissions taught me they weren’t worth obsessing about. I just needed to chmod and chown because I was consolidating my files into one account. Then software updates went bonkers. LOL That shows how easily you can go looking for trouble.
You can only change the “umask for home directory” through Yast, AFAIK.
Yes, but that should also affect newly created files in the user’s home directory.
(unless the umask is set explicitly via some other means)
Btw, I think that setting should be in YaST->Security and Users->User and Group Management.
Didn’t mean to imply is was located elsewhere. It was just the only setting I found with umask.
Nope. It only affects the user’s home directory. One thing I found out researching file permissions is that umask can be changed whenever you want. Try the following in Konsole:
umask (gives you the current umask setting)
umask 077 (changes it)
touch file.txt
ls -l file.txt (to check the permissions)
and close Konsole, restart it, and check the value of umask again. It should be back to the original. That’s basically how you can create the home directory with permissions very different from the system’s umask value.
Given the strict hierarchical nature of *nix, the setting “umask for home directory” makes sense. If it’s set with umask 077 then another user on the same computer cannot access your home directory and it therefore doesn’t matter if all your files inside it are e.g. world-readable.
And I’m going to stop displaying I’ve recently read up on this.
Ok, I was only trying to help.
Apparently you know better now anyway, and that is good… (and thanks for sharing your new insights) 