Joanna Rutkowska has always been a big supporter of the Windows Vista security model. Until she stumbled upon a 'very severe hole' in the design of UAC and found out - from Microsoft officials - that the default no-admin setting isn't even a security mechanism anymore. Rutkowska believes UAC has a major flaw in the way it automatically assumes that all setup programs (application installers) should be run with administrator privileges.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-07-24
Warning: tangential rant follows...
And it was possibly the single intelligent idea within zmd, for which everything else was horribly, horribly wrong.
I was one of the QA team working on ZENworks Linux Management 7, which is the product zmd was originally created for. zmd is essentially a rewrite of rcd, the Red Carpet Daemon, which was part of Ximian's Red Carpet Enterprise. The reason zmd and rcd needed to run as daemons is to enable system administrators to remotely manage the packages installed on the system (which is the primary selling point of RCE and ZENworks), and because RPM typically requires root privileges, those daemons ran as root. The fact that this allows normal users to do limited package management operations (as decided by the administrator) is a nice side effect of that.
The issues I believe you're referring to in zmd aren't exactly zmd's fault. zmd, as shipped in ZENworks, is relatively stable, fast, and reliable. But that's not the version of zmd most people saw.
See, zmd has a concept of "backends". The backend is essentially an abstraction layer around the underlying package management system. Backends handle package management tasks as well as doing dependency resultion. The backend that zmd shipped with in ZENworks is heavily based on libredcarpet, the old standby from Red Carpet Enterprise, and it works pretty well. However, SuSE Linux doesn't just consist of packages. It also has a concept of "patches", "patterns", and "products", which are meant to allow, among other things, for the vendor (Novell) to release operating system patches that do things other than just update a package (say, run a script, or display a EULA).
To allow for these new concepts, SuSE wrote a new package management library called libzypp, which contains its own dependency resolver and handles package management in its own way. This was entirely new code written for the release of OpenSUSE 10.0 and SLED/SLES 10. Unfortunately, libzypp doesn't exactly snap neatly into zmd. For an idea of what I'm talking about, see http://en.opensuse.org/Understanding_zmd , which contains a diagram I drew awhile back to explain the whole thing.
IIRC, if you don't care about patches/patterns/products (and I think most casual Linux users probably don't), it's still possible to install the libredcarpet backend, which will speed up zmd at least tenfold, along with other reliability benefits. I'm not sure who maintains the RPMs for that these days, but Google may be able to provide some clues.
Member since:2005-07-13
Fair enough, but it sort of underscores that zmd should not have been forklifted into Suse 10.1, and it was kind of clear that the decision to break version freeze during the beta phase in order to force it in came from the parent company for what I assume was to ensure testing before it was implemented into SLED 10.
I don't want to take away from the capability of Zenworks, and in fairness from what I've heard it was much more effective in SLED, which makes sense given the environment SLED was targeted for.
It was just a bad decision, and a poorly executed one, to put it into Suse, particularly since it offered no tangible benefits to anyone but Novell; I could live with that, given Novell's sponsorship of Suse, but not at the cost that was extracted in terms of useability and reputation for a solid, well founded distribution.
I wouldn't consider your post to be a rant, it's actually one of the most intelligent explanations for zmd and the reasoning behind it; and given the way zmd has been mercilessly slagged by the community (myself included) I can understand your desire to respond. But I still think it was a horrible decision that struck a black mark on Suse that exists to this day, though they've announced they're pulling it altogether for 10.3 I understand.
That doesn't take away from what it offers a Zenworks-managed infrastructure, just underscores the importance of using the right tool for the right job.
Member since:
2005-07-13
When I try to install an RPM, it complains about not having permission to interact with the RPM database. Am I missing something?
That's correct AFAIK, the rpm db is restricted. You can extract an rpm as a user and manually install it, but then it may as well be a .tar file.
Suse/Novell tried to work around this to a certain extent with the ill-fated zmd framework; it used dbus to allow an updater application running under regular user permissions to signal the package management daemon to selectively download and install signed updates, which effectively worked around the rpm permission issues without requiring the actual user to authenticate as root. And it was possibly the single intelligent idea within zmd, for which everything else was horribly, horribly wrong.