Ben Armstrong wrote:
Horribly complex. What is wrong with having a Unix group 'admin' and only show menu items if the user belongs to group admin? If the overhead of maintaining members of an admin group is something that a sys admin doesn't want to bother with, the sys admin could simply decide (via some option in /etc/menu-methods/menu.config perhaps) that all users on the system should see all admin menu entries. Or if a particular user doesn't want to pester the admin to add them to group admin, yet does have root access somehow, then the same config variable should be settable under ~/.menu/
I'd concede that it is possibly too complex - on reflection I think that it would be fine just to base whether a menu item is shown on whether the user is capable of using sudo to run it with the required uid. There is no need to fall back to su, as it's use for things like this should probably be discouraged anyway, and arguably there is no need to have a manual override in the configuration, as if the user has sudo access to something then hiding it in the menu won't achieve much.
However, I think that having an admin group is not the way to do it, as:a) You then have the case that the list of people who can change uid in a nice graphical way is the intersection of two lists which must be separately maintained - /etc/sudoers and the members of the admin group, and I believe that this sort of thing should be avioided if at all possible.
b) It is not flexible enough - individual users may have sudo access to a limited set of executables, and the sane thing to do would be for only those items to appear in the menu. I think that having menu items which don't work is a bad idea.
The only way I can see to get round this is to base the menu on the contents of /etc/sudoers.
Phil -- To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org