[1.7] passwd: useless if used with a logged on domain user
Mon Mar 23 15:33:00 GMT 2009
On Mar 23 14:35, J?lio Costa wrote:
> On Sun, Mar 22, 2009 at 19:22, Corinna Vinschen wrote:
> > On Mar 22 17:34, J?lio Costa wrote:
> >> ~ $ # Just typed Ctrl-C. Not in the mood right now :)
> >> ~ $ # And now for the interesting part:
> >> ~ $ ./my_passwd.exe -S SYSTEM
> >> my_passwd: unknown user SYSTEM
> > The SYSTEM user is not in the user database. Â So that's an expected
> > result.
> It is in mine:
> ~ $ grep system /etc/passwd
Let me rephrase:
"The SYSTEM user is not in the *Windows* user database."
> I've come to some conclusions in this process. Here they are:
> #1 li -> usri3_priv (line 552, 587 and 594) will only tell you if the
> logged on user is (isn't) admin in his/her LOGON domain! But what is
> needed here is to know if the logged on user is (isn't) admin in the
> TARGET domain/server, where is the TARGET account!
So you mean we should rather check if the user is in the Administrators
> #2 Just querying (-S) the account characteristics does not need Admin
> priviledges, so the test in 552 should be done instead inside the
> if@576; And should be a different test, from what is said in #1;
> #3 Generally, commands in Windows without providing additional
> information defaults to the local machine. So should passwd.
> Currently, I'm forced to say '-d $HOSTNAME' to ensure that the target
> user is really on the local machine. This is not coherent behaviour
> because it depends or not on if the current logged on user cames from
> a domain or is local. Currently the csih script breaks in his call to
> passwd due to this. Which breaks sshd-host-config (and maybe others?)
> I think the most coherent behaviour should be: 'if '-d' is not
> supplied, the TARGET domain is always LOCAL; otherwise, follow
> supplied domain'. It is precisely how NET USER and friends works, with
> the '/DOMAIN' parameter, with the added tweak that you don't even have
> to name the logon domain (although it could be done like this in
> passwd also, i think...)
That sounds about right. I agree. Except in the case I'm just calling
`passwd' without a user name in which case I definitely want to change
my own password.
> But I'll keep trying to achieve a stable version. Unless, of course,
> you think that this is not "the way"(tm) to do it...
Using CheckTokenMembership isn't quite the way to go. If I understand
you right that the idea is just checking if the token contains the
well-known Administrators group, I'll check in something equivalent.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin