Discussion:
Disabling updater applet
(too old to reply)
Christoph Bartoschek
2010-10-12 12:31:10 UTC
Permalink
Hi,

how can I disable the updater applet for all users of the system. They are
not allowed to install packages anyway?

Christoph
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
ka1ifq
2010-10-12 15:00:47 UTC
Permalink
Post by Christoph Bartoschek
Hi,
how can I disable the updater applet for all users of the system. They are
not allowed to install packages anyway?
Christoph
Right click on applet, configure applet, you can disable it there.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2010-10-12 16:35:30 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by ka1ifq
Post by Christoph Bartoschek
how can I disable the updater applet for all users of the system. They are
not allowed to install packages anyway?
Christoph
Right click on applet, configure applet, you can disable it there.
AFAIK, that does not work for all users and all desktops. All of them
would have to do the change themselves.


I would think of changing the ownership of the daemon:

- -rwxr-xr-x 1 root root 287448 2010-04-23 02:38 /usr/sbin/packagekitd*

Remove the allow execute for all, perhaps.

- --
Cheers,
Carlos E. R.
(from 11.2 x86_64 "Emerald" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEARECAAYFAky0jlkACgkQtTMYHG2NR9XuYACeLrwH68vvMdXogIuNe2QIoYsL
g/MAoImr39JrF+cM5mzBhlZb5oxeXTKm
=iF4r
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Will Stephenson
2010-10-12 16:46:51 UTC
Permalink
Post by Christoph Bartoschek
how can I disable the updater applet for all users of the system. They are
not allowed to install packages anyway?
Generally, review the Autostart spec:

http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html

Identify the applet's autostart desktop file (rpm -ql the applet's package)
and hide it.


In concrete steps, for the KDE update applet:

Add Hidden=true to

/etc/xdg/autostart/kupdateapplet-autostart.desktop

HTH

Will
--
Will Stephenson, openSUSE Team
SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
k***@hawaii.rr.com
2010-10-12 18:41:44 UTC
Permalink
Post by Will Stephenson
Post by Christoph Bartoschek
how can I disable the updater applet for all users of the system. They
are not allowed to install packages anyway?
http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html
Identify the applet's autostart desktop file (rpm -ql the applet's package)
and hide it.
Add Hidden=true to
/etc/xdg/autostart/kupdateapplet-autostart.desktop
HTH
Will
--
Will Stephenson, openSUSE Team
SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus
Rex
Will,
not trying to start a war or anything, but, this is a typical little crappy
issue that aggravates too many of us with ...ok, i will say it...kde4, if
kde4 is the cause, or with the new versions of shtuff in general, if kde4 is
not the cause.

WHY is something as basic as this so contorted and so difficult to accomplish?
And, the really maddening shtuff, WHY is the apparent straightforward process
still allowed to proceed without error messages, thus giving one the false
security that the task has actually been accomplished?
at the absolute very minimum, let the default be such that only if one changes
it and then tries to change it back the issue arises.
sometimes even when things are not right, simple common sense can still avoid
problems.
all,
please do *not* build on this another kde4 basher thread. all i tried to do is
point something that is too general for a bug report, yet it needs fixing
asap.
d.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
John Andersen
2010-10-12 19:01:19 UTC
Permalink
Post by k***@hawaii.rr.com
WHY is something as basic as this so contorted and so difficult to accomplish?
And, the really maddening shtuff, WHY is the apparent straightforward process
still allowed to proceed without error messages, thus giving one the false
security that the task has actually been accomplished?
at the absolute very minimum, let the default be such that only if one changes
it and then tries to change it back the issue arises.
sometimes even when things are not right, simple common sense can still avoid
problems.
all,
please do *not* build on this another kde4 basher thread. all i tried to do is
point something that is too general for a bug report, yet it needs fixing
asap.
d.
Well first, I think there are two problems here.

One is lack of documentation.

Two is the installation of tools like this by default on accounts that can't
use them.

I don't think this second bit is entirely a KDE4 issue.

But consider that Opensuse (and kde in general) has no way of knowing which users
are to be eligible to use these tools, and at what level (Notify only, silent install,
or download but don't install). There is no why to know in advance which users
have roots password tucked away in their head.

The vast majority of linux installs have exactly ONE user anyway.

Ubuntu assumes the first user account should be added to the sudoers list to
manage the machine. (This can be over-ridden, and many argue that the assumption
is a trap for the unwary, but there it is anyway).

Unless or Until OpenSuse embraces sudo as the normal way of doing system
tasks and integrates this into the normal installation and requires that
each new user added to the system is explicitly added to the sudo list, there
doesn't seem to be an easy way out.

In the absence of consistent use of the sudo, and sudoers, there is no way
for KDE to know which users should or should not be allowed to run
updater or file manager super user mode, or konsole super users mode.

So I don't think you can blame KDE entirely when it has no method of
determining which passwords a user might hold.

You might want to suggest a multi-user install option with some mechanism
for KDE to hook into when start up options and menus are constructed.
Perhaps management of this type of install could be better integrated
into yast.
--
_____________________________________
At one time I had a Real Sig. Its been downsized.
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Christoph Bartoschek
2010-10-12 21:42:06 UTC
Permalink
Post by Will Stephenson
Post by Christoph Bartoschek
how can I disable the updater applet for all users of the system. They are
not allowed to install packages anyway?
http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html
Identify the applet's autostart desktop file (rpm -ql the applet's package)
and hide it.
Add Hidden=true to
/etc/xdg/autostart/kupdateapplet-autostart.desktop
Thanks for the information.

It seems as if Packagekit is responsible for the messages. Would it be
sufficient and recommended to deinstall all packages related to Packagekit?

Christoph
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2010-10-12 22:24:26 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by John Andersen
Well first, I think there are two problems here.
One is lack of documentation.
That's a general problem.
Post by John Andersen
Two is the installation of tools like this by default on accounts that can't
use them.
Yes.
Post by John Andersen
I don't think this second bit is entirely a KDE4 issue.
No, it is not. Gnome has the same problem.
Post by John Andersen
But consider that Opensuse (and kde in general) has no way of knowing which users
are to be eligible to use these tools, and at what level (Notify only, silent install,
or download but don't install). There is no why to know in advance which users
have roots password tucked away in their head.
It is very simple, in fact: just list them in a file. A variable in a file
in /etc/sysconfig/updatenotifier.
Post by John Andersen
Unless or Until OpenSuse embraces sudo as the normal way of doing system
No, I disagree. I hope openSUSE never embraces sudo as the normal way of
doing things. And it is not needed for this at all.

There are several methods. One, is change the permissions of the applet or
the underlying daemon, so that a normal user, unless he belongs to a
certain group, can not run it. Another is listing in a file which users
can use some special tools.

- --
Cheers,
Carlos E. R.
(from 11.2 x86_64 "Emerald" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEARECAAYFAky04CIACgkQtTMYHG2NR9V59gCeJp1wwSs100ngef6sw/KZSsmO
y8gAni1Km59GfqDKF7ziNZuOS6pJiS3v
=QIYh
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
John Andersen
2010-10-12 23:14:14 UTC
Permalink
There are several methods. One, is change the permissions of the applet or the underlying daemon, so that a normal user, unless he belongs
to a certain group, can not run it. Another is listing in a file which users can use some special tools.
Seriously Carlos?
You want someone to create yet another nonstandard file to list people?

There are standards for this already, some followed, some not.
Wasn't that what the Wheel group was for?
Isn't that what sudoers was for?
--
_____________________________________
---This space for rent---
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2010-10-12 23:39:40 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by John Andersen
There are several methods. One, is change the permissions of the applet or the underlying daemon, so that a normal user, unless he belongs
to a certain group, can not run it. Another is listing in a file which users can use some special tools.
Seriously Carlos?
Yes, seriously.
Post by John Andersen
You want someone to create yet another nonstandard file to list people?
Why not?
We are only talking of PackageKit, not of any standard.
Post by John Andersen
There are standards for this already, some followed, some not.
Wasn't that what the Wheel group was for?
That's what I'm using >:-)
Post by John Andersen
Isn't that what sudoers was for?
Sudoers is not configured in default opensuse system, it would be
impossible to start now, just for one program, by the distro. It is up to
you, the admin, to do it.

Say, how would you configure sudoers to make the updater applet not
appear? Which is the main question here.

- --
Cheers,
Carlos E. R.
(from 11.2 x86_64 "Emerald" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEARECAAYFAky08cQACgkQtTMYHG2NR9WDlACgifNsk0BXQuvr3kvrx+JWq6vg
qjcAnA+oLFFGCTwo6lpMOJQMHdEott54
=sRxh
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
John Andersen
2010-10-13 03:05:58 UTC
Permalink
Say, how would you configure sudoers to make the updater applet not appear? Which is the main question here.
I would have updater check if user is in the list, and exit immediately of not.
But I'm sure it could be made more complex and obtuse than that. ;-)
--
_____________________________________
---This space for rent---
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2010-10-13 03:26:41 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by John Andersen
Say, how would you configure sudoers to make the updater applet not appear? Which is the main question here.
I would have updater check if user is in the list, and exit immediately of not.
But I'm sure it could be made more complex and obtuse than that. ;-)
I know that.

But that does not solve the OP problem: he is an admin, not a dev. He can
not rewrite the updater.

And even for a future version of the distro, that would need a complete
generation of the sudoers file, a change of policy... on which I do not
agree. This is not ubuntu, and I like our ways.

- --
Cheers,
Carlos E. R.
(from 11.2 x86_64 "Emerald" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEARECAAYFAky1JvoACgkQtTMYHG2NR9XPXQCgj5r74kByU7V7zT4BiyZKKGdY
/zgAnjkCtilFrt2pEj7WVi3YNMBajoJr
=g271
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2010-10-12 22:37:00 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Christoph Bartoschek
Thanks for the information.
It seems as if Packagekit is responsible for the messages. Would it be
sufficient and recommended to deinstall all packages related to Packagekit?
That would be:

rpm --erase PackageKit libpackagekit-glib12 kupdateapplet-packagekit gnome-packagekit kupdateapplet


I think it is better to just change the daemon permissions; I have done
that, but it's early to know if it works, but we'll see.

- --
Cheers,
Carlos E. R.
(from 11.2 x86_64 "Emerald" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEARECAAYFAky04w0ACgkQtTMYHG2NR9UQDgCfe2eyDEsTO9biKOSaHY6e6IL8
SpIAnjnZfO6qcRRQvQlUjFJfNxlYHwl5
=jDC+
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Christoph Bartoschek
2010-10-12 22:48:31 UTC
Permalink
Post by Carlos E. R.
I think it is better to just change the daemon permissions; I have done
that, but it's early to know if it works, but we'll see.
I do not want to give any user the permission to install packages.

This can easily disrupt the work of other users.

Christoph
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2010-10-12 23:07:29 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Christoph Bartoschek
Post by Carlos E. R.
I think it is better to just change the daemon permissions; I have done
that, but it's early to know if it works, but we'll see.
I do not want to give any user the permission to install packages.
Who said anything about giving permission? I did not. I removed
permissions.

- --
Cheers,
Carlos E. R.
(from 11.2 x86_64 "Emerald" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEARECAAYFAky06joACgkQtTMYHG2NR9UwnQCdGF88zyKChW145UfmxYyBzyGZ
9uwAmwXT2pPNzRYVpx3jdyJfm+4KeE4j
=qHQG
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Steven L Hess
2010-10-12 23:25:41 UTC
Permalink
Post by Christoph Bartoschek
Post by Carlos E. R.
I think it is better to just change the daemon permissions; I have done
that, but it's early to know if it works, but we'll see.
I do not want to give any user the permission to install packages.
This can easily disrupt the work of other users.
Christoph
How is anyone going to install anything without root permission?

Steven
--
Sent from my Linux box.
Regards de KC6KGE.
A very happy Flex-3000 user.
Skype flamebait
Gmail flamebait at gmail dot com
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Anton Aylward
2010-10-12 23:49:27 UTC
Permalink
Post by Steven L Hess
Post by Christoph Bartoschek
Post by Carlos E. R.
I think it is better to just change the daemon permissions; I have done
that, but it's early to know if it works, but we'll see.
I do not want to give any user the permission to install packages.
This can easily disrupt the work of other users.
Christoph
How is anyone going to install anything without root permission?
Obviously not.

The question you _SHOULD_ be asking is how to restrict access to root,
yet grant it in limited circumstances.

Which is what SUDO and PAM are about.
See pam_sepermit(8) pam_wheel(8) pam_listfile(8)

Oh, and the concept of the "wheel group".

Oh, and judicious use of group permission and setuid :-)
--
APL is a mistake, carried through to perfection. It is
the language of the future for the programming techniques
of the past: it creates a new generation of coding bums.
-- Edsger W. Dijkstra,
SIGPLAN Notices, Volume 17, Number 5
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Christoph Bartoschek
2010-10-13 06:18:39 UTC
Permalink
Post by Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Christoph Bartoschek
Post by Carlos E. R.
I think it is better to just change the daemon permissions; I have done
that, but it's early to know if it works, but we'll see.
I do not want to give any user the permission to install packages.
Who said anything about giving permission? I did not. I removed
permissions.
Sorry. I misunderstood your post.

Christoph
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Marcus Meissner
2010-10-24 20:54:54 UTC
Permalink
The permission handling between the updater applet and the PackageKit daemon is actually
done via PolicyKit. You can adjust its rules if necessary.
Documented where? It looks like chinese to me.
Telcontar:~ # chmod o-x,g-x /usr/sbin/packagekitd
Telcontar:~ # l /usr/sbin/packagekitd
-rwxr--r-- 1 root root 287448 Apr 23 02:38 /usr/sbin/packagekitd*
But it is still running, and as the root user.
Well, it is started as "root", so you need to remove its root access permissions
if you never want to run packagekit at all.
# package kit
#
org.freedesktop.packagekit.package-install auth_admin_keep_always
org.freedesktop.packagekit.package-install-untrusted auth_admin
org.freedesktop.packagekit.system-trust-signing-key auth_admin
org.freedesktop.packagekit.package-eula-accept auth_admin_keep_always:auth_admin_keep_always:yes
org.freedesktop.packagekit.package-remove auth_admin_keep_always
org.freedesktop.packagekit.system-update auth_admin_keep_always
org.freedesktop.packagekit.system-rollback auth_admin_keep_always
org.freedesktop.packagekit.system-sources-configure auth_admin_keep_always
org.freedesktop.packagekit.system-sources-refresh auth_admin_keep_always:auth_admin_keep_always:yes
org.freedesktop.packagekit.system-network-proxy-configure auth_admin_keep_always
org.freedesktop.packagekit.cancel-foreign auth_admin:auth_admin:auth_admin_keep
#
How does this work? The names look arbitrary to me, no guessing what they
do, no guessing what names are available. I don't see there how to deny a
user to run the daemon and learn there are updates.
That's chinese to me.
auth_admin will ask for admin privileges. auth_admin_keep_always will keep it after you have netered them once.

Having all lines with "no" at the end will probably disable them, like:
org.freedesktop.packagekit.package-install no

CIao, Marcus
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Carlos E. R.
2010-10-24 22:51:57 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Marcus Meissner
-rwxr--r-- 1 root root 287448 Apr 23 02:38 /usr/sbin/packagekitd*
But it is still running, and as the root user.
Well, it is started as "root", so you need to remove its root access permissions
if you never want to run packagekit at all.
I'm logged as user, so if it runs as root it means that another process
which is running as root (not me), or SUID, is calling it.
Post by Marcus Meissner
# package kit
#
org.freedesktop.packagekit.package-install auth_admin_keep_always
org.freedesktop.packagekit.package-install-untrusted auth_admin
org.freedesktop.packagekit.system-trust-signing-key auth_admin
org.freedesktop.packagekit.package-eula-accept auth_admin_keep_always:auth_admin_keep_always:yes
org.freedesktop.packagekit.package-remove auth_admin_keep_always
org.freedesktop.packagekit.system-update auth_admin_keep_always
org.freedesktop.packagekit.system-rollback auth_admin_keep_always
org.freedesktop.packagekit.system-sources-configure auth_admin_keep_always
org.freedesktop.packagekit.system-sources-refresh auth_admin_keep_always:auth_admin_keep_always:yes
org.freedesktop.packagekit.system-network-proxy-configure auth_admin_keep_always
org.freedesktop.packagekit.cancel-foreign auth_admin:auth_admin:auth_admin_keep
#
How does this work? The names look arbitrary to me, no guessing what they
do, no guessing what names are available. I don't see there how to deny a
user to run the daemon and learn there are updates.
That's chinese to me.
auth_admin will ask for admin privileges. auth_admin_keep_always will keep it after you have netered them once.
I see.
Post by Marcus Meissner
org.freedesktop.packagekit.package-install no
But which is the process that searches for updates in the first place?
That's the one that should not run, that's the one we need to remove - and
I don't see it there. This is a process that never asks for permissions.
It runs and tells the users that there are updates.

Only the user that also is the admin should be informed.


An example.

I log as me normal user in Gnome. After a while, I'm automatically
informed that there are some updates, and I choose to not install for the
moment (close window).

Then I choose to also log in on another graphical user, another user, in
gnome or kde. And this user is also informed that there are updates!

This is absurd.

In this case it is the same person, but it could be guest, a child, an
employee... whoever.

Only those users that do maintenance of the machine should have the applet
running that checks for updates, and there is no known method to control
this. I tried using permissions on packagekid, but no success.

- --
Cheers,
Carlos E. R.
(from 11.2 x86_64 "Emerald" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEARECAAYFAkzEuJsACgkQtTMYHG2NR9WYDgCdEcOU+Sndfx/L34jqs+J2YlgL
GWwAnRGxlhZnArwGCB+hxDubG4Pfo5kV
=c86z
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
For additional commands, e-mail: opensuse+***@opensuse.org
Loading...