GNU bug report logs -
#57386
29.0.50; support make-symbolic-link without admin priviledge on Windows
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57386 in the body.
You can then email your comments to 57386 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Wed, 24 Aug 2022 15:35:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kiên Nguyễn Quang <kien.n.quang <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 24 Aug 2022 15:35:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The CreateSymbolicLink Win32API has a flag that allows creating sym-links
without admin privileges SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE.
This patch added that support for w32 Emacs.
[Message part 2 (text/html, inline)]
[0001-symlink-allow-w32-user-to-create-symlink-without-adm.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Wed, 24 Aug 2022 16:01:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 57386 <at> debbugs.gnu.org (full text, mbox):
> From: Kiên Nguyễn Quang
> <kien.n.quang <at> gmail.com>
> Date: Thu, 25 Aug 2022 00:33:58 +0900
>
> The CreateSymbolicLink Win32API has a flag that allows creating sym-links without admin privileges
> SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE.
> This patch added that support for w32 Emacs.
Thanks, but we cannot use that flag unconditionally, because it is not
supported on all Windows versions. The addition of the flags should
be conditioned on the version of Windows on which Emacs runs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Wed, 24 Aug 2022 18:06:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 57386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
You're right, there's a stupid check against parameters on the version that
doesn't support the new flag.
Since from Windows 10, the Windows version checking is not recommended (and
not accurate) anymore, I think we can just retry if the function is called
with invalid parameters.
That will probably slow down the down-level Windows versions, but the
difference should not be too much.
On Thu, Aug 25, 2022 at 1:00 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Kiên Nguyễn Quang
> > <kien.n.quang <at> gmail.com>
> > Date: Thu, 25 Aug 2022 00:33:58 +0900
> >
> > The CreateSymbolicLink Win32API has a flag that allows creating
> sym-links without admin privileges
> > SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE.
> > This patch added that support for w32 Emacs.
>
> Thanks, but we cannot use that flag unconditionally, because it is not
> supported on all Windows versions. The addition of the flags should
> be conditioned on the version of Windows on which Emacs runs.
>
[Message part 2 (text/html, inline)]
[0001-symlink-allow-w32-user-to-create-symlink-without-adm.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Wed, 24 Aug 2022 18:27:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 57386 <at> debbugs.gnu.org (full text, mbox):
> From: Kiên Nguyễn Quang <kien.n.quang <at> gmail.com>
> Date: Thu, 25 Aug 2022 03:05:37 +0900
> Cc: 57386 <at> debbugs.gnu.org
>
> You're right, there's a stupid check against parameters on the version that doesn't support the new flag.
> Since from Windows 10, the Windows version checking is not recommended (and not accurate) anymore, I
> think we can just retry if the function is called with invalid parameters.
> That will probably slow down the down-level Windows versions, but the difference should not be too much.
Unfortunately, invalid parameters could cause Emacs to abort,
depending on how it was linked. So I still think checking the version
of Windows is the way to go. That MS don't recommend that doesn't
mean we must abide by their recommendations.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Thu, 25 Aug 2022 01:31:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 57386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
In my new patch, if we received the ERROR_INVALID_PARAMETER, we will try to
create the symbolic link again without the new flag.
Isn't that ok for now?
The Windows version API has returned the same thing from the start of
Windows 10 so we pretty much can't detect the Windows version by using it.
Unless we read the information directly from the registry and parse it by
ourselves, which is something I would like to avoid.
On Thu, Aug 25, 2022 at 3:26 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Kiên Nguyễn Quang <kien.n.quang <at> gmail.com>
> > Date: Thu, 25 Aug 2022 03:05:37 +0900
> > Cc: 57386 <at> debbugs.gnu.org
> >
> > You're right, there's a stupid check against parameters on the version
> that doesn't support the new flag.
> > Since from Windows 10, the Windows version checking is not recommended
> (and not accurate) anymore, I
> > think we can just retry if the function is called with invalid
> parameters.
> > That will probably slow down the down-level Windows versions, but the
> difference should not be too much.
>
> Unfortunately, invalid parameters could cause Emacs to abort,
> depending on how it was linked. So I still think checking the version
> of Windows is the way to go. That MS don't recommend that doesn't
> mean we must abide by their recommendations.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Thu, 25 Aug 2022 05:51:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 57386 <at> debbugs.gnu.org (full text, mbox):
> From: Kiên Nguyễn Quang <kien.n.quang <at> gmail.com>
> Date: Thu, 25 Aug 2022 10:30:01 +0900
> Cc: 57386 <at> debbugs.gnu.org
>
> In my new patch, if we received the ERROR_INVALID_PARAMETER, we will try to create the symbolic link
> again without the new flag.
> Isn't that ok for now?
Sorry, no. I want to avoid the ERROR_INVALID_PARAMETER error
entirely, for the reasons I explained up-thread. That error happens
only if the underlying Windows version is too old and doesn't support
this flag, so a version check will avoid it. If the Windows version
is new enough, that error will never happen, even if the Developer
Option is not activated; instead, the call will simply fail (with
ERROR_PRIVILEGE_NOT_HELD) as if the flag were never used. So checking
the Windows version will allow us not to trigger the invalid parameter
error, and will also avoid calling the API twice.
> The Windows version API has returned the same thing from the start of Windows 10 so we pretty much
> can't detect the Windows version by using it.
> Unless we read the information directly from the registry and parse it by ourselves, which is something I
> would like to avoid.
That's a separate problem, which we will resolve if and when it
becomes relevant. For now, this problem doesn't exist, since AFAIK
there are no features yet which we want to use that are available only
in Windows 11 and later. So please assume that version checks in
Emacs are reliable, and always will be, no matter what MS says about
that.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Thu, 25 Aug 2022 08:54:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 57386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
>
> That's a separate problem, which we will resolve if and when it
> becomes relevant. For now, this problem doesn't exist, since AFAIK
> there are no features yet which we want to use that are available only
> in Windows 11 and later. So please assume that version checks in
> Emacs are reliable, and always will be, no matter what MS says about
> that.
>
> Thanks.
>
The new flag is available starting from Windows 10 Creator update, which
means two (or 3? I don't know) updates after the first Windows 10 release.
Since the version returned for all Windows 10 are the same, you see, that's
the problem.
I think the error is already caught and should be replaced with the new one
if we retry calling the API, can you elaborate more on how it can still
affect Emacs?
Is there somewhere Emacs is calling GetLastError without invoking the API
so the stored error is mistakenly used?
Thanks
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Thu, 25 Aug 2022 09:10:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 57386 <at> debbugs.gnu.org (full text, mbox):
> From: Kiên Nguyễn Quang <kien.n.quang <at> gmail.com>
> Date: Thu, 25 Aug 2022 17:52:50 +0900
> Cc: 57386 <at> debbugs.gnu.org
>
> That's a separate problem, which we will resolve if and when it
> becomes relevant. For now, this problem doesn't exist, since AFAIK
> there are no features yet which we want to use that are available only
> in Windows 11 and later. So please assume that version checks in
> Emacs are reliable, and always will be, no matter what MS says about
> that.
>
> Thanks.
>
> The new flag is available starting from Windows 10 Creator update, which means two (or 3? I don't know)
> updates after the first Windows 10 release.
> Since the version returned for all Windows 10 are the same, you see, that's the problem.
If that's the problem (is anyone who has Windows 10 still likely to
use those old releases, given the automatic updates in Windows 10 that
cannot be turned off? and if they do, do they indeed get
ERROR_INVALID_PARAMETER?), we can handle that as well. We have
already an API for accessing the Registry (see w32-read-registry and
its C counterpart w32_read_registry), and report-emacs-bug already
uses it to obtain the full description of the version, the build
number and all. If needed, we can use a similar technique to make an
accurate version test.
> I think the error is already caught and should be replaced with the new one if we retry calling the API, can you
> elaborate more on how it can still affect Emacs?
When you call an API with a parameter that is invalid, you are risking
an exception, depending on the API and the build (debug or not). This
has various unpleasant consequences; in the worst case, the Emacs
process could be terminated. As documented, the problem is limited to
CRT functions, but our general policy is to avoid that even when using
the Win32 APIs. And version check is a simple enough way of avoiding
that, so I see no reason not to do it here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Thu, 25 Aug 2022 09:52:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 57386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
>
> (is anyone who has Windows 10 still likely to
> use those old releases, given the automatic updates in Windows 10 that
> cannot be turned off? and if they do, do they indeed get
> ERROR_INVALID_PARAMETER?)
>
There is LTS branch of Windows that gets updated regularly and doesn't have
to update to a newer release build.
Those users (mostly enterprise users/devs) will get the
ERROR_INVALID_PARAMETER, I've tested that.
> When you call an API with a parameter that is invalid, you are risking
> an exception, depending on the API and the build (debug or not). This
> has various unpleasant consequences; in the worst case, the Emacs
> process could be terminated. As documented, the problem is limited to
> CRT functions, but our general policy is to avoid that even when using
> the Win32 APIs. And version check is a simple enough way of avoiding
> that, so I see no reason not to do it here.
Okay, that makes sense. Although I think that's the problem of CRT APIs
only, as API should never throw exceptions, which is a foreign concept to
ABI and requires an exact library match to handle correctly
The new patch is attached.
[Message part 2 (text/html, inline)]
[0002-Make-native-comp-debug-0-for-Windows.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Thu, 25 Aug 2022 09:58:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 57386 <at> debbugs.gnu.org (full text, mbox):
> From: Kiên Nguyễn Quang <kien.n.quang <at> gmail.com>
> Date: Thu, 25 Aug 2022 18:51:30 +0900
> Cc: 57386 <at> debbugs.gnu.org
>
> > When you call an API with a parameter that is invalid, you are risking
> > an exception, depending on the API and the build (debug or not). This
> > has various unpleasant consequences; in the worst case, the Emacs
> > process could be terminated. As documented, the problem is limited to
> > CRT functions, but our general policy is to avoid that even when using
> > the Win32 APIs. And version check is a simple enough way of avoiding
> > that, so I see no reason not to do it here.
>
> Okay, that makes sense. Although I think that's the problem of CRT APIs only, as API should never throw
> exceptions, which is a foreign concept to ABI and requires an exact library match to handle correctly
>
> The new patch is attached.
Thanks, but I think you sent a wrong patch?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Thu, 25 Aug 2022 10:33:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 57386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Oops. Here it is.
On Thu, Aug 25, 2022 at 6:57 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Kiên Nguyễn Quang <kien.n.quang <at> gmail.com>
> > Date: Thu, 25 Aug 2022 18:51:30 +0900
> > Cc: 57386 <at> debbugs.gnu.org
> >
> > > When you call an API with a parameter that is invalid, you are risking
> > > an exception, depending on the API and the build (debug or not). This
> > > has various unpleasant consequences; in the worst case, the Emacs
> > > process could be terminated. As documented, the problem is limited to
> > > CRT functions, but our general policy is to avoid that even when using
> > > the Win32 APIs. And version check is a simple enough way of avoiding
> > > that, so I see no reason not to do it here.
> >
> > Okay, that makes sense. Although I think that's the problem of CRT APIs
> only, as API should never throw
> > exceptions, which is a foreign concept to ABI and requires an exact
> library match to handle correctly
> >
> > The new patch is attached.
>
> Thanks, but I think you sent a wrong patch?
>
--
Nguyen Quang Kien - グエン クアン キエン
Software Developer @ MSD
[Message part 2 (text/html, inline)]
[0001-symlink-allow-w32-user-to-create-symlink-without-adm.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Thu, 25 Aug 2022 11:36:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 57386 <at> debbugs.gnu.org (full text, mbox):
Kiên Nguyễn Quang <kien.n.quang <at> gmail.com> writes:
> There is LTS branch of Windows that gets updated regularly and doesn't
> have to update to a newer release build. Those users (mostly
> enterprise users/devs) will get the ERROR_INVALID_PARAMETER, I've
> tested that.
What about Windows 95 and 98? Will reading the registry to obtain the
API version return correct values there as well?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57386
; Package
emacs
.
(Thu, 25 Aug 2022 13:00:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 57386 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 57386 <at> debbugs.gnu.org
> Date: Thu, 25 Aug 2022 19:35:39 +0800
>
> Kiên Nguyễn Quang <kien.n.quang <at> gmail.com> writes:
>
> > There is LTS branch of Windows that gets updated regularly and doesn't
> > have to update to a newer release build. Those users (mostly
> > enterprise users/devs) will get the ERROR_INVALID_PARAMETER, I've
> > tested that.
>
> What about Windows 95 and 98? Will reading the registry to obtain the
> API version return correct values there as well?
It should, although I never had a chance of testing that.
But the patch eventually submitted doesn't access the Registry at all.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Thu, 25 Aug 2022 13:23:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Kiên Nguyễn Quang <kien.n.quang <at> gmail.com>
:
bug acknowledged by developer.
(Thu, 25 Aug 2022 13:23:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 57386-done <at> debbugs.gnu.org (full text, mbox):
> From: Kiên Nguyễn Quang <kien.n.quang <at> gmail.com>
> Date: Thu, 25 Aug 2022 19:32:13 +0900
> Cc: 57386 <at> debbugs.gnu.org
>
> Oops. Here it is.
Thanks. I installed this (with minor changes), but please in the
future make sure your commit log messages follow our conventions (as
described in CONTRIBUTE), because this patch was rejected by our Git
commit hooks, and I had to apply it "by hand".
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 23 Sep 2022 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 326 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.