Re: passwd-* confusing PostInst message

On 6/12/12 1:00 PM, Daniel Macks wrote:
> On 10.7, installing the various passwd-* packages prompts (via PostInst) for confirmation before merging the specific user/group into the system. However, it *always* does this, even when reinstalling. So:
> 
> $ fink install passwd-games
> ["Y" to accept]
> 
> $ id games
> uid=253(games) gid=253(games) groups=253(games),12(everyone),61(localaccounts)
> $ fink install passwd-games
> [same prompt, noting that the existing user/uid/etc will be overwritten]
> 
> Now that we're moving towards being sensitive to systems that have non-simple user/authentication arrangements (network logins, "not just fink" doing funky stuff locally, etc.), we should at least provide some recognition of the current state of affairs before giving such a scary-looking prompt. At a minimum, the PostInst should check for and display existing entries for the user/uid that would be created. Then the message could be more specific about things being overwritten vs created vs "it's already as expected, do you want to reinstall anyway? [default=N]". Otherwise every time we update passwd, all fink users have to pause and think about how to procede (often blindly, which we should not be promoting) with system-level modifications for no reason. 
> 
> dan
> 
>  --
> Daniel Macks
> [email protected]
> 
> 

Yeah, passwd has a lot of pre-10.4 baggage.

I propose the following (on 10.7, at any rate):

1) verify that all of the packages packages that use the passwd users
are using the user names rather than UID/GID numbers.  I don't see a
compelling reason why a "games" user with UID 601 provided in a netork
login situation is any different than a "games" user with UID 253
installed via passwd-games.

2)  The postinst checks for an existing id. If the id exists, the
existing UID and GID are displayed.  If it doesn't exist, move on to 5)

3) If these match the entries in /sw/etc/passwd-fink and
/sw/etc/group-fink, then don't bother saying anything more.  Skip to 4)
  If these don't match /sw/etc/passwd-fink and /sw/etc/group-fink,
suggest that the user modify those files to shut these messages up. :-)

4) Give the user a timed prompt, with a "No" default, asking whether to
overload their existing values with those in /sw/etc/passwd-fink and
/sw/etc/group-fink.  That way people don't check on their machines
following an overnight build to discover that a passwd user update has
blocked their batch build in order to apply _no_ change to their system.
:-)  "No" means "Done", "Yes" means go on to 5).

5)  If the id does not exist, or if the user elects to apply the values
from /sw/etc/passwd-fink and /sw/etc/group-fink, then we display a
variant on the existing message, warning that that we're going to add a
user with the given properties, and wait for authorization to do so, as
we do currently.

An additional extension would be to allocate UIDs and GIDs from a pool
by default (fink can do this for fink-bld) rather than having
predetermined values.
-- 
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
fink-core mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core