Conflicting design issue for hide-admin-tools-to-users

Martin Pitt wrote:
> ... This can lead to unexpected privilege escalation, and also would
> probably break horribly when using a centralized authentication
> database (NIS, LDAP, etc).

We could probably sanely check for centralized authentication, and if
there's any doubt about whether it's used, we could skip that part of
the upgrade. Don't misunderstand me: I'm not convinced this is a good
solution, only that it's a whole lot better than having a warty design
decision impact the usability and security of all future releases.

Centralized authentication aside, not putting any users into the admin
group during an upgrade (which added the group) would mean that the
actual administrator has the 'Users and groups' applet initially hidden
from her view, and so she wouldn't be able to add herself and other
administrators to the group without dropping into the console. Dropping
into the console for this is a usability regression from the current
situation, but this entire discussion came up when talking about
privileged menu entries being hidden from non-administrators, which is a
usability issue to begin with.

Bottom line: damned if you do, damned if you don't.

I suppose an alternative approach is to have a package in Dapper, e.g.
warty-system-upgrades, which can be mentioned in the Dapper release
notes but needs to be installed by hand, and which is a catchall package
bringing a fully standard warty install -- no centralized authentication
-- into compliance with any Dapper design decisions that conflict those
in Warty. This gives a clean, non-forced automatic upgrade path to
Dapper for simple, desktop users who are upgrading from Warty, or have
already upgraded to a more recent release without reinstall. But I'm not
sure I like that solution, either.

-- 
Ivan Krstic <krstic at fas.harvard.edu> | 0x147C722D