Why user without sudo priviliges can use Muon?

[gnomek]

I created a user_2 that has no sudo privilages:

user@user_2 ~ $ id
uid=1001(user_2) gid=1001(user_2) grupy=1001(user_2),4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),29(audio),30(dip),44(video),46(plugdev),104(fuse),115(nopasswdlogin)

When I do sudo apt-get update it tells me to type in administrative password for user_2 and gives me back information that this user is not in sudoers group, which is correct behaviour.
But I can still do updates with Moun and install programs from this account and it ask me for administrative password of user_1 and accepts it.
Has this something to do with group 4(adm)?

Basically I created this account for myself, because I think it is a little bit more safer to not work on administrative account and even don't use administrative password on this account.

[kubicle]

I created a user_2 that has no sudo privilages:
Has this something to do with group 4(adm)?

No. The purpose of the 'adm' group is system monitoring (namely to give read access to most of the logs in /var/log for it's members), it isn't related to authentication (unless you've specifically modified sudoers to give sudo privileges to the adm group, of course).

I believe the difference in authentication behavior you are experiencing is the difference between sudo and policykit (which is a separate/alternative authentication method with it's own configuration...in other words, sudo configuration doesn't affect policykit authentication). I don't have Muon installed, but I believe it uses policykit as the authentication method instead of sudo.

[apachelogger]

I believe the difference in authentication behavior you are experiencing is the difference between sudo and policykit (which is a separate/alternative authentication method with it's own configuration...in other words, sudo configuration doesn't affect policykit authentication). I don't have Muon installed, but I believe it uses policykit as the authentication method instead of sudo.

Exactly.

Though truth be told, you can just as well use apt-get form a non-sudo user, you just need to switch to a user that is in the sudo group.

For example
$ su user_1 # switches the user to user_1 who is in sudo
$ sudo apt-get install foo # runs sudo as user_1 thus allowing sudo to work

It is essentially the same concept as polkit, there you'd also authenticate as user_1 except it is less intrusive as it is a built in feature. For example your son does not have sudo access on his computer but wants you to install a deb. You'd click the deb and authenticate as an admin user to complete the installation. It is also similar to what Windows does, there if you have a non-admin user and try to do an administrative task you also can choose to authenticate as administrator to execute the task.

[gnomek]

Are there any policykit authentication settings in Kubuntu where I can switch this behaviour off?

[oshunluvr]

Not an answer to your question, but you can remove the update notifier and check manually.

[kubicle]

Are there any policykit authentication settings in Kubuntu where I can switch this behaviour off?

Probably (but like apachelogger already mentioned, that doesn't really prevent a non-privileged user to run things as root if the user knows an admin user's password...as the user can easily switch to that user).

Unfortunately, I haven't had a reason to dig into policykit configuration and cannot offer advice on what would be the sanest way to modify the behaviour, so you'll probably better off checking the internet and man pages (unless someone else can pitch in)

Some man pages to start with: 'man polkit', 'man pklocalauthority', 'man pkaction', 'man pkcheck'
A command to check existing policykit authentication rules: 'pkaction --verbose'