Hi Eli,
> > Your patch is consistent with the behaviour of this code on Unix,
> > when the user does not exist.
>
> Yes, but the current code already behaves like that, it just doesn't
> say so.
Yes, that's what I'm saying. I made a positive statement about your
patch :)
> > But would it not be possible to support the ~user syntax also on
> > Windows? By creating a gnulib module 'getpwnam' based on the
> > function GetUserProfileDirectory() [1][2] ?
>
> AFAIK, GetUserProfileDirectory for another user requires that you know
> that user's credentials. For example, one of the links you sent talks
> about LogonUser, which will ask for that user's password.
In the small test program I wrote, that uses LogonUser followed by
GetUserProfileDirectory, the LogonUser function always fails with
error ERROR_LOGON_FAILURE when a NULL password is specified.
> The MS docs
> of LogonUser says:
>
> The LogonUser function attempts to log a user on to the local
> computer. The local computer is the computer from which LogonUser
> was called. You cannot use LogonUser to log on to a remote
> computer. You specify the user with a user name and domain and
> authenticate the user with a plaintext password. If the function
> succeeds, you receive a handle to a token that represents the
> logged-on user. You can then use this token handle to impersonate
> the specified user or, in most cases, to create a process that runs
> in the context of the specified user.
>
> I don't think it's reasonable for a library to ask for a password
Right.
> and
> for any non-trivial user account the chances of the current user to be
> able to type the password are probably nil. (The example on
> StackOverflow uses "guest", which may mean this account has no
> password.)
>
> It _is_ possible to get the information using the NetUserGetInfo API.
> However, for a local computer that API always returns an empty string
> for the user's home directory (as AFAIU local accounts don't record
> this information, only domain servers do). And in any case, this and
> other similar APIs cannot return the accurate results if the other
> user defines HOME to point to somewhere else; access to environment
> variables of another user again requires that user's credentials.
>
> So I think trying to make a fully-functional getpwnam on Windows is
> more trouble than it's worth, and in all practical applications I've
> seen (including Emacs, for example), supporting ~USER for the current
> user is more than enough.
>
I agree with all this. I'm applying your patch, with more comments:
2021-04-02 Bruno Haible <br...@clisp.org>
glob: Reject ~user syntax, when flag GLOB_TILDE_CHECK is given.
Reported and patch suggested by Eli Zaretskii <e...@gnu.org> in
<https://lists.gnu.org/archive/html/bug-gnulib/2021-03/msg00136.html>.
* lib/glob.c (__glob) [WINDOWS32]: If flag GLOB_TILDE_CHECK is given, do
error handling like when ~user is allowed by the user is unknown.
diff --git a/lib/glob.c b/lib/glob.c
index 775911e..e148f8d 100644
--- a/lib/glob.c
+++ b/lib/glob.c
@@ -743,6 +743,8 @@ __glob (const char *pattern, int flags, int (*errfunc)
(const char *, int),
else
{
#ifndef WINDOWS32
+ /* Recognize ~user as a shorthand for the specified user's home
+ directory. */
char *end_name = strchr (dirname, '/');
char *user_name;
int malloc_user_name = 0;
@@ -881,7 +883,22 @@ __glob (const char *pattern, int flags, int (*errfunc)
(const char *, int),
}
scratch_buffer_free (&pwtmpbuf);
}
-#endif /* !WINDOWS32 */
+#else /* WINDOWS32 */
+ /* On native Windows, access to a user's home directory
+ (via GetUserProfileDirectory) or to a user's environment
+ variables (via ExpandEnvironmentStringsForUser) requires
+ the credentials of the user. Therefore we cannot support
+ the ~user syntax on this platform.
+ Handling ~user specially (and treat it like plain ~) if
+ user is getenv ("USERNAME") would not be a good idea,
+ since it would make people think that ~user is supported
+ in general. */
+ if (flags & GLOB_TILDE_CHECK)
+ {
+ retval = GLOB_NOMATCH;
+ goto out;
+ }
+#endif /* WINDOWS32 */
}
}
