Re: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)

[Warren Young <warren at etr-usa dot com>]

On 2/6/2014 07:13, Corinna Vinschen wrote:
> Btw., it would be a good idea to get rid of calls to getpwent/getgrent
> in future.  They *probably* won't do anymore what they were supposed to
> do if you don't have passwd/group files.

There must be a way to list an executable's DLL imports, and thereby do 
a survey on Cygwin to see which executables currently import those 
functions.  If so, I know a guy who currently has all of Cygwin 
downloaded and ready to re-install, to test this. :)

I tried futzing with objdump, nm, and dumpbin, and couldn't get anything 
useful.  Mainly what I got was either irrelevant or complaints of the 
"no string table" sort.

> A full implementation would
> require to enumerate the local SAM and, at least, the primary domain
> accounts at runtime.  That would be possible, but it comes at a hefty
> price in terms of performance.

Linux and Cygwin are pretty much the last ones standing when it comes to 
preferentially reading plain text files in /etc for user info.  Big iron 
Unix, the BSDs, and Mac OS X now all treat these files as secondary to 
some behind-the-scenes database.

In some of these systems, you can edit /etc/foo and run a command to 
manually sync that content back to the "real" user info DB.  (e.g. the 
BSDs)  In others, direct edits to these files are ignored, but the OS 
syncs a subset of changes to the user info DB to these files, for the 
benefit of getpwent() and friends.  (e.g. Mac OS X.)

In Cygwin, we have a kind of hybrid of these, owing to the fact that the 
integration between Cygwin and Windows is pretty much one-way.  We have 
mkpasswd/group, which treats the DB as primary, like OS X, but which 
must be run manually to sync changes, like the BSDs.

I don't see a reason for this to change, given that so many other POSIX 
systems share aspects of this behavior.

It would be nicer if Cygwin behaved more like OS X in this regard. 
That is, for mkpasswd/group to be run automatically when the SAM/AD 
changes.  I don't see Microsoft doing that for us, though.

The only way I can think of for Cygwin to do that for itself would be to 
run mkpasswd/group from setup.exe, in the same way that it runs 
autorebase.

I realize the current recommended practice is to keep /etc/foo as small 
as possible, but shouldn't an AD/SAM DB lookup be faster than a linear 
scan of a large /etc/foo file?  Why lament the fact that getpwent() is 
slow, when getpwnam() is its logical replacement, and presumably much 
faster?

(I assume getpwnam() consults SAM/AD in Cygwin, now or in Cygwin.next.)

Here's the Mac OS X passwd(5) man page: http://goo.gl/AwIHku

It's relevant here because Mac OS X uses OpenDirectory, an LDAP 
directory server.  In that way, it is not unlike future-Cygwin+AD.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple