This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Feb  6 14:43, Warren Young wrote:
> 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. :)

Try this:  strings -f /bin/*.exe /bin/*.dll | grep getgrent

> > 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.

Which would be SAM and AD for us.

> 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.)

That won't make much sense on Cygwin.  The idea is to use the existing
OS tools to maintain the user/group databases in the first place.
Having said that, it would, of course, be possible to implement Cygwin
command line tools along the lines of useradd/usermod/groupdel.  For AD,
they would just have to use LDAP, as Cygwin will do to read the account
info.  It's pretty simple, as far as you view LDAP as simple,

> 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.

That won't be necessary anymore.  In fact, I would prefer if we could
do without the passswd and group files, but we have to keep them
for backward compatibility at least.

However, I found that one functionality has to go completely.  It will
not be possible anymore to ssh into your machine and add yourself to
arbitrary groups by adding your user name to groups in /etc/group.  This
is just not feasible anymore.

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

Sorry, I lost you there.  What exactly of the current behaviour do
you want to keep?

> 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.

Cygwin will directly read from SAM/AD.  What's the point of automating
writing passwd and group files?  Also, the usual problem:  What exactly
do you write to passwd/group?  If you write all users of a big corp,
the files get really big.  So far, every exec'ing process is reading
the files anew.  This is *so* 1990ths.

> 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.

Sorry, but that sounds rather backward to me.  And again, what exactly
do you write to the files?  Only local accunts?  Or local and primary
domain?  Or local, primary domain and all trusted domains?  And what do
you do with local changes to the files?  mkpasswd/mkgroup would
overwrite all changes, which does not sound like a terribly good idea to
me.

> 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 don't lament the fact.  The problem is that a SAM/AD scan would have
to be implemented in Cygwin in the first place.  And then again, what do
you suppose Cygwin should do in big AD forests?  Enumerate all accounts
of all trusted domains?  As of today, this is an unsolved problem,


Corinna

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

It checks for the file first, then it asks SAM/AD.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpnuKPzriQmI.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]