Bug 215619

you granted this right for running the zen-updater likely.

run:
$ rug ul

Username | Privileges                                        
---------+---------------------------------------------------
<user> | subscribe, upgrade, install, refresh, view, remove

The remove permission grants you to remove any RPM.

Thank you for this, however we assigned a privileged user to ZMD in order that online update notification can function. If I change the user permission away from root the ZMD will not work and display updates I think...This is why at first installation we are promoted for root authority. The notification part of ZMD is fine, however t extend ZMD to the desktop to have complete authority to uninstal perhaps all software is dangerous. Perhaps when we are asked for a privileged user after install we should be prompted for a user with authority from ZMD to indicate updates. I really never understood after install why ZMD requested privileged user password

so you are saying that the user has no ZMD permission but still can rewmove packages?

(In reply to comment #1)
> you granted this right for running the zen-updater likely.
> 
> Username | Privileges                                        
> ---------+---------------------------------------------------
> <user> | subscribe, upgrade, install, refresh, view, remove

Exactly this is the problem - when zen-updater asks to add the user as trusted user, it should give as little permissions as necessary. IMHO the "remove" permissions are not needed to keep the system up to date, the install and subscribe permissions are also questionable.

At least this is expected behaviour - nobody expects that someone can break the system (by uninstalling random packages) when granting permissions to run the online update tool (zen-updater) which is used to install bug/security fixes.

(In reply to comment #4)
> IMHO the "remove" permissions are not
> needed to keep the system up to date

Are you sure? I am not.

There are upgrade operations (e.g. conflicting and obsoleting packages) which imply removal of a package.

Remember your own proposal from bug 213512: It implies removal of package.

Please forgive me jumping in here, however bug indicated in #5 is in regard to installing clamAV originally in YAST as a root user. I don't see the issue, however I am first to admit I don't understand the rest of the issues in #5 above.

More pointedly bug https://bugzilla.novell.com/show_bug.cgi?id=214956 calls for the complete re-assessment of the current online update and ZMD association.

With version 10.1 when we moved to ZEN updater replaced SuSe watcher we introduced a massive number of issues, this now being one. There have been no less that 4 different version published online update.

I have strong issue that a service runs freenly under root credentials, in-order to function, is available and accessible without the user needing to log in as root.

ZEN updater neeeds serious re-evaluation as to its effectiveness/ its current issues and this new issue.

I do not understand why we move from susewatcher to ZEN updater. certainly I understand it was portaled from the Novell ZEN desktop updater the was used in a Novell NetWare environment where the MS-Windows Client was already running Administrator permissions for Zen Desktop updater to function.

To move an application such as ZEN updater to a Linux environment and subsequently for the desktop user to grant the application root authority just to function and leave the application open and running with permitted escalation of authority is flawed in a Linux environment. 

ZEN updaters functionality and now security issues needs strong re-evaluation to continue its use in the product Linux where the user can run normally under a least privileged account.

(In reply to comment #5)
> (In reply to comment #4)
> > IMHO the "remove" permissions are not
> > needed to keep the system up to date
> 
> Are you sure? I am not.

I'm not that familar with zenworks, so: no, I'm not sure.

> There are upgrade operations (e.g. conflicting and obsoleting packages) which
> imply removal of a package.
> 
> Remember your own proposal from bug 213512: It implies removal of package.

Yes, using "Obsoletes:". If this really needs "remove" permissions the permission system of zenworks is more broken than I was already afraid :-(
and needs to be changed.

(In reply to comment #7)
> Yes, using "Obsoletes:". If this really needs "remove" permissions the
> permission system of zenworks is more broken than I was already afraid :-(
> and needs to be changed.

And if "Obsoletes" is silently permitted even without "remove" permissions, it's broken as well - in a different way, but still broken - because the removal of an obsoleted packages is indeed still a package removal and that way one (1) mistakenly obsoleting package in one of these broken repositories people are using these days can break the whole system even without that the system administrator can prevent it other than withdrawing even more zmd privileges than "remove".

The whole approach is wrong in general and this bug is not a bug. Withdrawing the erroneously granted "remove" privilege is the needed user action here. "Obsoletes" processing is a topic per se, it's one of the most frequently abused RPM tags and the fact that e.g. YUM ignores it completely by default shows that it is problematic, changing the defaults in this area needs more considerations than just "it needs to be changed".

The other issue with both the software removal tool is it ability to indicate dependencies  issues, however it does not try to resolve the dependencies issues in a way like software Management/Sofware update does.

This issue that a user has control over installation and removal of the total package, as we have given ZEN root authority to run by any user is not helpful and I would advocate its complete removal from the version.

On one hand we think of YAST having root permissions to effect the total installation update or software Management and that's where it should remain.

Giving a user escalated permissions when setting it up if flawed - both from a security and it ability to identify dependency issues, and fail to provide help in deselecting or adding a component which has dependency issues and only being able to identify them but offer NO solution which YAST Software Management and Online update possesses.

The value of the software install software and remove software should NOT be a user devission, however is a hang over of the Novell ZEN desktop installer in a Windows Environment has been given poor thought.

Please consider carefully if you want to consider ZEN and change back to the SUSE watcher before release 10.2.

10.1 will go down in history as the distro with the most problems with online update. Certainly with the number of bug reports associated with Online updates and ZEN and software management will need further management QA considerations.

Re. comment 1: if a cracker gains access to your account and you use kdesu to launch yast software management, you've lost, the cracker now has root's password.

Someone needs to perform these tasks, and the fewer tasks that need root's password the better

If you dont want the user to have this power, do not allow him to run zen-updater/zen-remover and so on.

it can be restricted ;)

With this issue and associated other bugs with ZEN the best thing to do is to disable the service as just about everyone in email list help recommends to do and just check for online updates once per week via YAST to collect updates

In YAST go to system services 'run levels' find ZEN – probably the last entry and click 'disable'

above