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
pgpfZHcITav69.pgp
Description: PGP signature
