On Feb 13 21:41, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Oh, hmm. Well, it might be possible, but somehow I'm not excited by the
> > idea. While it looks like getpwent is mostly used for this purpose, you
> > don't really know it. I think I'll try to implement it fully and then
> > let
Corinna Vinschen writes:
> Oh, hmm. Well, it might be possible, but somehow I'm not excited by the
> idea. While it looks like getpwent is mostly used for this purpose, you
> don't really know it. I think I'll try to implement it fully and then
> let the admin decide what to allow.
Configurable
On Feb 13 18:50, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Caching is wonderful for the usual requests for single entries from the
> > DB, and for this we have already two caches, the LSA cache and Cygwin's
> > own cache. But caching doesn't help at all when enumerating.
>
> Would it be p
Greetings, Achim Gratz!
> Corinna Vinschen writes:
>> Caching is wonderful for the usual requests for single entries from the
>> DB, and for this we have already two caches, the LSA cache and Cygwin's
>> own cache. But caching doesn't help at all when enumerating.
> Would it be possible to only
Corinna Vinschen writes:
> Caching is wonderful for the usual requests for single entries from the
> DB, and for this we have already two caches, the LSA cache and Cygwin's
> own cache. But caching doesn't help at all when enumerating.
Would it be possible to only look (for user name completion p
On Feb 13 10:43, Christopher Faylor wrote:
> On Thu, Feb 13, 2014 at 03:44:19PM +0100, Corinna Vinschen wrote:
> >Yes, I think so too. I have some preliminary code (actually, just
> >empty function shells right now) which are supposed to implement
> >full enumerating.
> >
> >However, system admins
On Thu, Feb 13, 2014 at 03:44:19PM +0100, Corinna Vinschen wrote:
>On Feb 13 09:35, Christopher Faylor wrote:
>> On Thu, Feb 13, 2014 at 11:00:25AM +0100, Corinna Vinschen wrote:
>> >On Feb 12 16:37, Christopher Faylor wrote:
>> >> On Wed, Feb 12, 2014 at 08:59:31PM +0100, Corinna Vinschen wrote:
>
On Feb 13 09:35, Christopher Faylor wrote:
> On Thu, Feb 13, 2014 at 11:00:25AM +0100, Corinna Vinschen wrote:
> >On Feb 12 16:37, Christopher Faylor wrote:
> >> On Wed, Feb 12, 2014 at 08:59:31PM +0100, Corinna Vinschen wrote:
> >> >There's only one tiny problem. Whatever I think about the full
>
On Thu, Feb 13, 2014 at 11:00:25AM +0100, Corinna Vinschen wrote:
>On Feb 12 16:37, Christopher Faylor wrote:
>> On Wed, Feb 12, 2014 at 08:59:31PM +0100, Corinna Vinschen wrote:
>> >There's only one tiny problem. Whatever I think about the full
>> >enumerate being right or wrong, I have this vagu
Greetings, Corinna Vinschen!
>> >There's only one tiny problem. Whatever I think about the full
>> >enumerate being right or wrong, I have this vague feeling that I'd like
>> >to have this implemented fully at one point. My cat disapproves, but we
>> >can't agree on everything, I guess. Another
On Feb 12 16:37, Christopher Faylor wrote:
> On Wed, Feb 12, 2014 at 08:59:31PM +0100, Corinna Vinschen wrote:
> >There's only one tiny problem. Whatever I think about the full
> >enumerate being right or wrong, I have this vague feeling that I'd like
> >to have this implemented fully at one point
On Wed, Feb 12, 2014 at 08:59:31PM +0100, Corinna Vinschen wrote:
>On Feb 12 11:16, Ken Brown wrote:
>> On 2/12/2014 4:08 AM, Corinna Vinschen wrote:
>> >On Feb 11 19:06, Eric Blake wrote:
>> >>On 02/11/2014 05:06 PM, Warren Young wrote:
>> >>>On 2/11/2014 16:25, David Stacey wrote:
>> getpwent
On Feb 12 11:16, Ken Brown wrote:
> On 2/12/2014 4:08 AM, Corinna Vinschen wrote:
> >On Feb 11 19:06, Eric Blake wrote:
> >>On 02/11/2014 05:06 PM, Warren Young wrote:
> >>>On 2/11/2014 16:25, David Stacey wrote:
> getpwent() is called in three different places.
> >>>
> >>>To those of you who h
Greetings, Ken Brown!
> What about the following compromise: If /etc/passwd exists, then
> getpwent behaves as it does currently. Otherwise, it returns a handful
> of entries, or possibly just the current user. This gives users a
> choice. If tab-completion in this situation is important to
On Wed, 12 Feb 2014, Ken Brown wrote:
On 2/12/2014 4:08 AM, Corinna Vinschen wrote:
On Feb 11 19:06, Eric Blake wrote:
On 02/11/2014 05:06 PM, Warren Young wrote:
On 2/11/2014 16:25, David Stacey wrote:
getpwent() is called in three different places.
To those of you who have investigated t
On 2/12/2014 4:08 AM, Corinna Vinschen wrote:
On Feb 11 19:06, Eric Blake wrote:
On 02/11/2014 05:06 PM, Warren Young wrote:
On 2/11/2014 16:25, David Stacey wrote:
getpwent() is called in three different places.
To those of you who have investigated these code paths: do any of them
look lik
On Wed, 12 Feb 2014, Corinna Vinschen wrote:
On Feb 11 19:06, Eric Blake wrote:
On 02/11/2014 05:06 PM, Warren Young wrote:
On 2/11/2014 16:25, David Stacey wrote:
getpwent() is called in three different places.
To those of you who have investigated these code paths: do any of them
look lik
Greetings, Corinna Vinschen!
> Either way, implementing a full getpwent requires to return the local
> users, the users of the primary domain, and the users of all trusted
> domains. I know of domains with 200K users and there are probably
> bigger ones. How long should a search take when a user
On Feb 11 19:06, Eric Blake wrote:
> On 02/11/2014 05:06 PM, Warren Young wrote:
> > On 2/11/2014 16:25, David Stacey wrote:
> >> getpwent() is called in three different places.
> >
> > To those of you who have investigated these code paths: do any of them
> > look like they couldn't be replaced b
Greetings, Warren Young!
>> problem was an assumption made in the 'checkfile' perl script: it was
>> assumed that cygwin1.dll is the first DLL listed by objdump.
> Details, details. :)
That's where is the devil, we know, right?
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 12.02.2014, <08:23>
So
On 02/11/2014 05:06 PM, Warren Young wrote:
> On 2/11/2014 16:25, David Stacey wrote:
>> getpwent() is called in three different places.
>
> To those of you who have investigated these code paths: do any of them
> look like they couldn't be replaced by getpwnam() or other calls that
> would let cy
On 2/11/2014 16:25, David Stacey wrote:
getpwent() is called in three different places.
To those of you who have investigated these code paths: do any of them
look like they couldn't be replaced by getpwnam() or other calls that
would let cygwin1.dll do single-record AD/SAM lookups, rather th
On 11/02/2014 02:25, Andrey Repin wrote:
Greetings, David Stacey!
Greetings, Andrey Repin! (I've wanted to type that for such a long time...)
I don't have my "almost everything" Cygwin install here to run it
against, so unless someone beats me to it, I won't be posting results
for man
Greetings, David Stacey!
>> I don't have my "almost everything" Cygwin install here to run it
>> against, so unless someone beats me to it, I won't be posting results
>> for many hours at least.
> Delighted to oblige. I ran your perl script on all executables and DLLs
> in /bin. Results attache
On 10/02/2014 19:49, Warren Young wrote:
I don't have my "almost everything" Cygwin install here to run it
against, so unless someone beats me to it, I won't be posting results
for many hours at least.
Delighted to oblige. I ran your perl script on all executables and DLLs
in /bin. Results at
On 2/10/2014 04:16, Peter Rosin wrote:
On 2014-02-10 10:02, Warren Young wrote:
there *has* to be a better way than strings(1) to extract an EXE's list of DLL
imports.
objdump -x /bin/foo.exe
Thank you!
-x turns on 6 other flags, the only one of which that really matters
here is -p. The
On 2014-02-10 10:02, Warren Young wrote:
> On Feb 9, 2014, at 9:37 AM, David Stacey wrote:
>
>> On 09/02/2014 15:45, Warren Young wrote:
>>> Results:
>>>
>>> /bin/cppcheck.exe
>>
>> As far as I can tell, cppcheck doesn't actually call getpwent() at all; this
>> is a false positive turned up by s
On Feb 9, 2014, at 9:37 AM, David Stacey wrote:
> On 09/02/2014 15:45, Warren Young wrote:
>> Results:
>>
>> /bin/cppcheck.exe
>
> As far as I can tell, cppcheck doesn't actually call getpwent() at all; this
> is a false positive turned up by strings(1).
Yeah, there *has* to be a better way t
On 09/02/2014 15:45, Warren Young wrote:
Results:
/bin/cppcheck.exe
This intrigued me. cppcheck is a static analyser, so what's it doing
with getpwent()? I had a nosy in the source code, and it appears that
cppcheck has a rule checking for POSIX calls that are not re-entrant. If
a call to g
On 2/9/2014 11:16 AM, Corinna Vinschen wrote:
On Feb 9 17:10, Corinna Vinschen wrote:
On Feb 9 08:45, Warren Young wrote:
On Feb 7, 2014, at 10:51 AM, Warren Young wrote:
Here's a better check that doesn't give false positives:
$ cat < checkfile
#!/bin/sh
if egrep -q '_getgren
On Feb 9 17:10, Corinna Vinschen wrote:
> On Feb 9 08:45, Warren Young wrote:
> > On Feb 7, 2014, at 10:51 AM, Warren Young wrote:
> >
> > > Here's a better check that doesn't give false positives:
> > >
> > >$ cat < checkfile
> > >#!/bin/sh
> > >if egrep -q '_getgrent(32|64)' "$1"
On Feb 9 08:45, Warren Young wrote:
> On Feb 7, 2014, at 10:51 AM, Warren Young wrote:
>
> > Here's a better check that doesn't give false positives:
> >
> >$ cat < checkfile
> >#!/bin/sh
> >if egrep -q '_getgrent(32|64)' "$1" ; then echo $1 ; fi
> >END
> >$ find /bin -name
On Feb 7, 2014, at 10:51 AM, Warren Young wrote:
> Here's a better check that doesn't give false positives:
>
>$ cat < checkfile
>#!/bin/sh
>if egrep -q '_getgrent(32|64)' "$1" ; then echo $1 ; fi
>END
>$ find /bin -name \*.exe -exec ./checkfile {} \;
The strings(1) call got
> and I fail to see how this is related to the on-the-fly generation of passwd
> and group entries
Well, if a cygwin app was run under such an account, it might be affected,
that's all...
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Feb 8, 2014, at 8:19 AM, Warren Young wrote:
> On Feb 7, 2014, at 5:40 PM, Andrey Repin wrote:
>
>> In either case, repeatedly requesting the same record in a short amount of
>> time will only test the system level cache.
>
> If that were true, moving the requested record around in /etc/pas
On Feb 7, 2014, at 5:40 PM, Andrey Repin wrote:
>>> I thought the point of the programme /was/ to call getpwnam() a million
>>> times.
Precisely.
> In either case, repeatedly requesting the same record in a short amount of
> time will only test the system level cache.
If that were true, moving
On Feb 7 21:49, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > I think SAM/AD will be mostly quicker
>
> I do not want to be a party pooper here, but have you checked how
> the AD approach will work from the unmanaged Windows service accounts?
No, and I fail to see how this is related to the on
Greetings, Larry Hall (Cygwin)!
This takes 7.1 seconds on my system, with a 12-line /etc/passwd file:
#include
#include
#include
int main(int argc, const char* argv[])
{
int i;
const char* user =
On 2/7/2014 5:45 PM, David Stacey wrote:
On 07/02/14 21:44, Larry Hall (Cygwin) wrote:
On 2/7/2014 3:09 PM, Warren Young wrote:
This takes 7.1 seconds on my system, with a 12-line /etc/passwd file:
#include
#include
#include
int main(int argc, const char* argv[])
On 07/02/14 21:44, Larry Hall (Cygwin) wrote:
On 2/7/2014 3:09 PM, Warren Young wrote:
This takes 7.1 seconds on my system, with a 12-line /etc/passwd file:
#include
#include
#include
int main(int argc, const char* argv[])
{
int i;
const cha
> I think SAM/AD will be mostly quicker
I do not want to be a party pooper here, but have you checked how
the AD approach will work from the unmanaged Windows service accounts?
We've been experiencing rather nasty effects of the M$ design that
when a host changes its password (it is required to,
On 2/7/2014 3:09 PM, Warren Young wrote:
This takes 7.1 seconds on my system, with a 12-line /etc/passwd file:
#include
#include
#include
int main(int argc, const char* argv[])
{
int i;
const char* user = argv[1];
if (!user) {
On Feb 7 13:09, Warren Young wrote:
> On 2/7/2014 02:49, Corinna Vinschen wrote:
> >On Feb 6 14:43, Warren Young wrote:
> >>On 2/6/2014 07:13, Corinna Vinschen wrote:
> >
> >it would, of course, be possible to implement Cygwin
> >command line tools along the lines of useradd/usermod/groupdel. Fo
On Feb 7 13:25, Warren Young wrote:
> On 2/7/2014 13:09, Warren Young wrote:
> >
> >I want getpwent() and friends to remain available, but to switch to
> >AD/SAM as primary, like OS X does all the time,
>
> I just realized that this means getpwent() turns into an AD database
> linear scan at AD s
On 2/7/2014 13:09, Warren Young wrote:
I want getpwent() and friends to remain available, but to switch to
AD/SAM as primary, like OS X does all the time,
I just realized that this means getpwent() turns into an AD database
linear scan at AD sites.
Hmmm...
I think I'm still in favor of the
On 2/7/2014 02:49, Corinna Vinschen wrote:
On Feb 6 14:43, Warren Young wrote:
On 2/6/2014 07:13, Corinna Vinschen wrote:
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,
If by "us
On Feb 7 10:51, Warren Young wrote:
> On 2/7/2014 06:53, David Stacey wrote:
> >On 07/02/2014 09:49, Corinna Vinschen wrote:
> >>On Feb 6 14:43, Warren Young wrote:
> >>>I know a guy who currently has all of
> >>>Cygwin downloaded and ready to re-install, to test this.:)
> >>Try this: strings -f
Greetings, Warren Young!
>> LDAP IS simple.
> Anything tied to a PKI is going to be pretty complex, no matter how
> simple the underlying tech is.
> Then there's the fact that LDAP derives from X.500, a prototypically
> overengineered OSI emission. DC=my,DC=sub,DC=domain,DC=com. P'tui!
Well
On 2/7/2014 06:53, David Stacey wrote:
On 07/02/2014 09:49, Corinna Vinschen wrote:
On Feb 6 14:43, Warren Young wrote:
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
Let me save you
On 2/7/2014 05:49, Andrey Repin wrote:
LDAP IS simple.
Anything tied to a PKI is going to be pretty complex, no matter how
simple the underlying tech is.
Then there's the fact that LDAP derives from X.500, a prototypically
overengineered OSI emission. DC=my,DC=sub,DC=domain,DC=com. P'tui
On 07/02/2014 09:49, Corinna Vinschen wrote:
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 pass
Greetings, Corinna Vinschen!
>> 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 t
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
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 thereb
54 matches
Mail list logo
