> a) root access, of course. I say user, but naturally the user has to > have root privileges to install. Thus there are suid (Evil!), su, and > sudo paths to root to consider. For true user workstations (student > systems in the dorms) you'd likely want the gui to just prompt them for > the root password when they crank it up and then run as root thereafter consolehelper does a nice job of managing this. > b) It makes it easy for a user to break the hell out of their system. > Not FUNDAMENTALLY any easier than yum itself, but the possibility of > accidentally removing (e.g.) procps because of mouse error. well, it's technically easier to rm -rf at the wrong time :) > d) This in turn creates a really interesting question: is it possible > to tag packages as "root" controlled vs "user" controlled, and permit > the gui only to mess with "user" controlled (basically userspace) > applications? Is it further possible to permit access to the user > portion (only) with e.g. sudo? This question really applies to yum as > well as the GUI. I like the idea but implementation would be difficult. There would clearly have to be profiles you could set up and grant powers to users. This would require some effort to get right. > Then there is the root thing and security -- how to permit a general > user to run e.g. yum install pvm (which definitely installs in > root-controlled /usr) without the root password, while NOT allowing them > to hack it so that yum gets pvm from their own private RPM (where "pvm" > is an suid root shell) and NOT allowing them to remove the kernel, libc, > or any other "critical" or protected component. Obviously a bit of a > chore, here. you could target and control that, it's not impossible. it's sort of a bluesky project - not a medium-term thing. -sv
