Re: Support GLOB_TILDE_CHECK for ~user in glob.c on MS-Windows

[Bruno Haible <bruno@clisp.org>]

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  <bruno@clisp.org>

	glob: Reject ~user syntax, when flag GLOB_TILDE_CHECK is given.
	Reported and patch suggested by Eli Zaretskii <eliz@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 */
         }
     }