GNU bug report logs -
#33847
27.0.50; emacsclient does not find server socket
Previous Next
Reported by: Ulrich Mueller <ulm <at> gentoo.org>
Date: Sun, 23 Dec 2018 09:49:01 UTC
Severity: normal
Tags: patch
Merged with 41707
Found in version 27.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33847 in the body.
You can then email your comments to 33847 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#33847; Package
emacs.
(Sun, 23 Dec 2018 09:49:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ulrich Mueller <ulm <at> gentoo.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 23 Dec 2018 09:49:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The master branch was recently updated to place the server socket in
XDG_RUNTIME_DIR, with a fallback to the previous TMPDIR location.
This will make emacsclient fail when the server has been started from
an environment where XDG_RUNTIME_DIR is not set.
For example, if emacs --daemon is started on a Gentoo system via
OpenRC's start-stop-daemon, then emacs will create the socket in
${TMPDIR}/emacs${UID}/, but emacsclient (in the user's X session)
will search for it in ${XDG_RUNTIME_DIR}/emacs/:
$ emacsclient -c
emacsclient: can't find socket; have you started the server?
emacsclient: To start the server in Emacs, type "M-x server-start".
emacsclient: No socket or alternate editor. Please use:
--socket-name
--server-file (or environment variable EMACS_SERVER_FILE)
--alternate-editor (or environment variable ALTERNATE_EDITOR)
(The reason is of course that start-stop-daemon does not set the XDG_*
variables. However, I don't see how it could do that in any reasonable
way. Presumably it would have to happen via PAM and ConsoleKit, but the
latter doesn't have a display at that point.)
Suggested solutions:
- Create the socket in a dir that is more readily available, for example
somewhere under ${HOME}/emacs.d/, or
- Have emacsclient fall back to TMPDIR as well when no socket is found
under XDG_RUNTIME_DIR.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 23 Dec 2018 16:21:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 33847 <at> debbugs.gnu.org (full text, mbox):
The specification of XDG_RUNTIME_DIR at
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables
says this:
| $XDG_RUNTIME_DIR defines the base directory relative to which
| user-specific non-essential runtime files and other file objects
| (such as sockets, named pipes, ...) should be stored. [...]
| The lifetime of the directory MUST be bound to the user being logged
| in. It MUST be created when the user first logs in and if the user
| fully logs out the directory MUST be removed. [...]
| Files in the directory MUST not survive reboot or a full
| logout/login cycle.
It explicitly says that the directory does not persist between login
sessions, whereas - at least in my understanding - an Emacs running as
a daemon is supposed to survive logout, so that the user can reconnect
to it later. (For example, I use that feature for persistent ERC
sessions.)
So, I would conclude that XDG_RUNTIME_DIR is not an appropriate
location for the socket of a daemon process.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Tue, 25 Dec 2018 21:03:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> Suggested solutions:
> - Create the socket in a dir that is more readily available, for example
> somewhere under ${HOME}/emacs.d/
Unfortunately that won't work well in general, as $HOME/emacs.d might not exist,
or it might be on a network file system where a host-specific file would be
inappropriate.
> - Have emacsclient fall back to TMPDIR as well when no socket is found
> under XDG_RUNTIME_DIR
This would run afoul of the security issues that led to the use of
XDG_RUNTIME_DIR in the first place.
Instead, I suggest unsetting XDG_RUNTIME_DIR if you wish to start an Emacs
client or server that is independent of your session and are on a host that is
secured well enough so that the security issues are of no concern.
Alternatively, you can use --socket-name when starting emacsclient.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Tue, 25 Dec 2018 23:30:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 33847 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 25 Dec 2018, Paul Eggert wrote:
> Instead, I suggest unsetting XDG_RUNTIME_DIR if you wish to start an
> Emacs client or server that is independent of your session and are on
> a host that is secured well enough so that the security issues are of
> no concern. Alternatively, you can use --socket-name when starting
> emacsclient.
IMHO that's not an acceptable solution. emacsclient should just work in
the default configuration, without requiring the user to jump through
hoops, and an Emacs daemon should persist between sessions (otherwise
"daemon" would be a misnomer). Or is that use case really so uncommon?
Also, if there is a security problem, how would it disappear by moving
the socket to XDG_RUNTIME_DIR? Note that other tools like "screen" also
place their sockets in a subdir of /tmp.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Wed, 26 Dec 2018 00:25:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Ulrich Mueller wrote:
> IMHO that's not an acceptable solution. emacsclient should just work in
> the default configuration, without requiring the user to jump through
> hoops, and an Emacs daemon should persist between sessions (otherwise
> "daemon" would be a misnomer). Or is that use case really so uncommon?
We have a conflict here between "just work" and security. There are multiple
workarounds for the problem that you mention; if none of them are convenient
enough perhaps you can suggest a more-convenient one. The default should be
secure, though.
> if there is a security problem, how would it disappear by moving
> the socket to XDG_RUNTIME_DIR? Note that other tools like "screen" also
> place their sockets in a subdir of /tmp.
XDG_RUNTIME_DIR is guaranteed to be a directory owned by the user and readable
and writable by nobody else. /tmp/emacsUID does not have that property.
Tools like 'screen' that predate XDG_RUNTIME_DIR traditionally suffered from
similar security problems. On my Fedora 29 platform, 'screen' works around the
problem by being setgid 'screen' and putting files under /run/screen/S-eggert,
where /run/screen is mode drwxrwxr-x with owner 'root' and group 'screen'. The
exact location of the /run/screen directory is platform-specific; I guess that
it typically used to be /tmp/screens but got moved due to security concerns.
The 'screen' workaround does not appear to apply to Emacs, since Emacs is
programmable and if Emacs were made setgid its users could easily modify Emacs's
behavior to manipulate the contents of any such /run/emacs directory in any way
they pleased.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Wed, 26 Dec 2018 02:29:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 33847 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 26 Dec 2018, Paul Eggert wrote:
>> IMHO that's not an acceptable solution. emacsclient should just work in
>> the default configuration, without requiring the user to jump through
>> hoops, and an Emacs daemon should persist between sessions (otherwise
>> "daemon" would be a misnomer). Or is that use case really so uncommon?
> We have a conflict here between "just work" and security. There are
> multiple workarounds for the problem that you mention; if none of them
> are convenient enough perhaps you can suggest a more-convenient one.
IMHO, unsetting a standard variable like XDG_RUNTIME_DIR (as you've
suggested above) in the user's session isn't really an option. And a
wrapper script around emacsclient would be just awkward.
Plus, as it is currently implemented, there isn't even a unique way to
override the socket's location. I notice that emacsclient will now
honour the EMACS_SOCKET_NAME variable, but then again, server.el doesn't
use it. So if we would want to override the socket's location at the
distro level (e.g., place it in /run/emacs/${USER}/), how could we do
that? Having to add configuration to both site-start.el and to the
user's environment seems less than optimal.
> The default should be secure, though.
If it is a security issue, then why isn't the fix in the emacs-26 branch
as well? Also, why is there still a fallback to TMPDIR, if that's
considered insecure?
>> if there is a security problem, how would it disappear by moving
>> the socket to XDG_RUNTIME_DIR? Note that other tools like "screen" also
>> place their sockets in a subdir of /tmp.
> XDG_RUNTIME_DIR is guaranteed to be a directory owned by the user and
> readable and writable by nobody else. /tmp/emacsUID does not have that
> property.
XDG_RUNTIME_DIR is simply not suitable for the purpose, because (by its
specification) it will disappear when the login session ends, leading to
an Emacs daemon process that has no socket and can no longer be
connected to. Of course, unless one assumes that the daemon will not
persist the login session, but what would be the point of starting Emacs
as a daemon then?
> The 'screen' workaround does not appear to apply to Emacs, since Emacs
> is programmable and if Emacs were made setgid its users could easily
> modify Emacs's behavior to manipulate the contents of any such
> /run/emacs directory in any way they pleased.
No need for Emacs itself to be setgid, because the directory could
be created by calling an auxiliary setgid program (similar to
update-game-score).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Wed, 26 Dec 2018 07:00:03 GMT)
Full text and
rfc822 format available.
Message #23 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Ulrich Mueller wrote:
> IMHO, unsetting a standard variable like XDG_RUNTIME_DIR (as you've
> suggested above) in the user's session isn't really an option.
You're right, unsetting it for an entire session would mean that you want all
programs (not just Emacs) to not use XDG_RUNTIME_DIR, and that sounds too
drastic. I don't recall suggesting that.
> And a
> wrapper script around emacsclient would be just awkward.
It's not *that* awkward, and it may be acceptable if the situation you describe
is unusual enough.
> Plus, as it is currently implemented, there isn't even a unique way to
> override the socket's location. I notice that emacsclient will now
> honour the EMACS_SOCKET_NAME variable, but then again, server.el doesn't
> use it.
Although I'm not a big fan of environment variables, it might make sense for
server.el to look at EMACS_SOCKET_NAME, for consistency with emacsclient.
> So if we would want to override the socket's location at the
> distro level (e.g., place it in /run/emacs/${USER}/), how could we do
> that?
There's no mechanism in Emacs to do that now. It would be OK to add one, I expect.
> If it is a security issue, then why isn't the fix in the emacs-26 branch
> as well?
emacs-26 at this point is meant for fixing regressions, and the problem in
question is not a regression. Anyway, this change was too risky for the emacs-26
branch.
> Also, why is there still a fallback to TMPDIR, if that's
> considered insecure?
On a system that doesn't set XDG_RUNTIME_DIR it was the best we could easily do.
If we can come up with something better for those systems, that would be good.
For systems with XDG_RUNTIME_DIR it would probably be better to not reinvent
this particular wheel. That is, for users who prefer Emacs to run only when they
are logged in, XDG_RUNTIME_DIR seems to be the way to go. For users who prefer
Emacs to always be running, even when they are not logged in, we should use some
other mechanism.
> XDG_RUNTIME_DIR is simply not suitable for the purpose, because (by its
> specification) it will disappear when the login session ends,
I think the idea is that XDG_RUNTIME_DIR disappears when all login sessions end,
so it might survive the current session.
>> The 'screen' workaround does not appear to apply to Emacs, since Emacs
>> is programmable and if Emacs were made setgid its users could easily
>> modify Emacs's behavior to manipulate the contents of any such
>> /run/emacs directory in any way they pleased.
>
> No need for Emacs itself to be setgid, because the directory could
> be created by calling an auxiliary setgid program (similar to
> update-game-score).
That might work, as a solution for people who want Emacs to keep running even
when they entirely log out.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Wed, 26 Dec 2018 15:15:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 33847 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 26 Dec 2018, Paul Eggert wrote:
> Ulrich Mueller wrote:
>> XDG_RUNTIME_DIR is simply not suitable for the purpose, because (by its
>> specification) it will disappear when the login session ends,
> I think the idea is that XDG_RUNTIME_DIR disappears when all login
> sessions end, so it might survive the current session.
I still don't see why XDG_RUNTIME_DIR would be more secure than using
a directory in TMPDIR. server.el seems to take all necessary precautions
to ensure that the directory is safe:
server-ensure-safe-dir is a compiled Lisp function in ‘server.el’.
(server-ensure-safe-dir DIR)
Make sure DIR is a directory with no race-condition issues.
Creates the directory if necessary and makes sure:
- there’s no symlink involved
- it’s owned by us
- it’s not readable/writable by anybody else.
In addition, emacsclient checks for the ownership of the socket before
connecting to it.
>> No need for Emacs itself to be setgid, because the directory could
>> be created by calling an auxiliary setgid program (similar to
>> update-game-score).
> That might work, as a solution for people who want Emacs to keep
> running even when they entirely log out.
It would also be rather complicated, and require creation of an emacs
group. Using a directory where the user has write access is easier.
AFAICS, the three candidates for that are TMPDIR, HOME, and
XDG_RUNTIME_DIR.
Emacs 26 uses ${TMPDIR}/emacs${UID}/ or ${HOME}/.emacs.d/server/
depending on the server-use-tcp flag. Emacs 27 will use one of these
two or ${XDG_RUNTIME_DIR} as a default (depending on the environment).
IMHO this is approaching the point where things become unpredictable
and hard to understand for the user. (And making it more customizable
won't make it simpler, I fear.)
If TMPDIR really is insecure (see above), can't the socket be placed
in ${HOME}/.emacs.d/ which is already used in the TCP case? The socket
could be named server-<system-name>, in order to avoid issues with NFS
mounted directories.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Wed, 26 Dec 2018 18:33:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Ulrich Mueller wrote:
> server.el seems to take all necessary precautions
> to ensure that the directory is safe:
> (server-ensure-safe-dir DIR)
>
> Make sure DIR is a directory with no race-condition issues.
> Creates the directory if necessary and makes sure:
> - there’s no symlink involved
> - it’s owned by us
> - it’s not readable/writable by anybody else.
The problem on the server side isn't in server-ensure-safe-dir, it's that
something could happen between the time that server-ensure-safe-dir checks that
DIR is safe, and the time that DIR is actually used.
> In addition, emacsclient checks for the ownership of the socket before
> connecting to it.
Sure, but that doesn't mean it's the right socket. We discussed this last month;
please see the thread containing:
https://lists.gnu.org/archive/html/emacs-devel/2018-11/msg00051.html
>>> No need for Emacs itself to be setgid, because the directory could
>>> be created by calling an auxiliary setgid program (similar to
>>> update-game-score).
>
>> That might work, as a solution for people who want Emacs to keep
>> running even when they entirely log out.
>
> It would also be rather complicated, and require creation of an emacs
> group.
True. I also would prefer a better solution than that.
> Emacs 26 uses ${TMPDIR}/emacs${UID}/ or ${HOME}/.emacs.d/server/
> depending on the server-use-tcp flag. Emacs 27 will use one of these
> two or ${XDG_RUNTIME_DIR} as a default (depending on the environment).
> IMHO this is approaching the point where things become unpredictable
> and hard to understand for the user. (And making it more customizable
> won't make it simpler, I fear.)
True, it has gotten more complicated. If we could simplify it without reopening
the security holes that would be a good thing.
> can't the socket be placed
> in ${HOME}/.emacs.d/ which is already used in the TCP case? The socket
> could be named server-<system-name>, in order to avoid issues with NFS
> mounted directories.
That would cause problems when Emacs crashes or the system reboots, since the
directory wouldn't be cleaned up automatically. So although we could add this as
an option, I'm a bit leery of making it the default.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Thu, 27 Dec 2018 03:40:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 33847 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Tools like 'screen' that predate XDG_RUNTIME_DIR traditionally suffered from
> similar security problems. On my Fedora 29 platform, 'screen' works around the
> problem by being setgid 'screen' and putting files under /run/screen/S-eggert,
> where /run/screen is mode drwxrwxr-x with owner 'root' and group 'screen'. The
> exact location of the /run/screen directory is platform-specific; I guess that
> it typically used to be /tmp/screens but got moved due to security concerns.
Is it possible to arrange for each user to have a directory under /run/emacs
which is owned by that user and doesn't give access to anyone else?
Maybe we could release a simple setuid program to create that directory.
--
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Thu, 27 Dec 2018 16:43:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman wrote:
> Is it possible to arrange for each user to have a directory under /run/emacs
> which is owned by that user and doesn't give access to anyone else?
>
> Maybe we could release a simple setuid program to create that directory.
Although I think that would work, as Ulrich wrote in Bug#33847#26 it has an
operational problem: it requires the creation and installation of either a
setuid program (which will raise eyebrows) or the creation of a new 'emacs'
group and installation of a setgid 'emacs' program (which will raise fewer
eyebrows but is still a hassle). Adding either requirement would be a hassle for
builders and installers (e.g., how do you test the new Emacs before installing
it if you don't have rights to create a setuid program in the build directory?).
So we are looking for a better solution if possible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Thu, 27 Dec 2018 17:14:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Ulrich, have you tried starting your Emacs server as a lingering service?
Lingering seems to be designed for the sort of thing you want to do. Look for
"enable-linger" in <https://www.freedesktop.org/software/systemd/man/loginctl.html>.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Fri, 28 Dec 2018 06:20:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 33847 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 27 Dec 2018, Paul Eggert wrote:
> Ulrich, have you tried starting your Emacs server as a lingering
> service? Lingering seems to be designed for the sort of thing you want
> to do. Look for "enable-linger" in
> <https://www.freedesktop.org/software/systemd/man/loginctl.html>.
That would require systemd, so it is not a solution that can be
universally used. Especially it is GNU/Linux specific.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Fri, 28 Dec 2018 06:36:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Ulrich Mueller wrote:
>> Ulrich, have you tried starting your Emacs server as a lingering
>> service? Lingering seems to be designed for the sort of thing you want
>> to do. Look for "enable-linger" in
>> <https://www.freedesktop.org/software/systemd/man/loginctl.html>.
> That would require systemd, so it is not a solution that can be
> universally used. Especially it is GNU/Linux specific.
We don't need to attack the problem in general, only the problem on platforms
that have XDG_RUNTIME_DIR. What sort of platforms have XDG_RUNTIME_DIR but do
not use systemd, and how does one start a user-specific server on such platforms?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Fri, 28 Dec 2018 06:39:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 33847 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 26 Dec 2018, Paul Eggert wrote:
>> can't the socket be placed in ${HOME}/.emacs.d/ which is already used
>> in the TCP case? The socket could be named server-<system-name>, in
>> order to avoid issues with NFS mounted directories.
> That would cause problems when Emacs crashes or the system reboots,
> since the directory wouldn't be cleaned up automatically. So although
> we could add this as an option, I'm a bit leery of making it the
> default.
The only problem I see is that it would leave a stale socket file
behind, when Emacs is not properly terminated. That file would be
deleted/replaced the next time an Emacs server is started.
I guess in the typical use case we are talking about a single inode.
If the home directory is NFS mounted it may be one inode per machine.
I think that's a small price to pay, for a solution that would be both
very simple, would be available on all systems, and won't suffer from
security issues.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Fri, 28 Dec 2018 06:52:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 33847 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 28 Dec 2018, Paul Eggert wrote:
> We don't need to attack the problem in general, only the problem on
> platforms that have XDG_RUNTIME_DIR. What sort of platforms have
> XDG_RUNTIME_DIR but do not use systemd, and how does one start a
> user-specific server on such platforms?
See my original report, OpenRC and start-stop-daemon.
So you're saying that on systems that don't have XDG_RUNTIME_DIR,
placing the socket under TMPDIR is fine? Because I don't understand
that argument. If TMPDIR has security problem, then it shouldn't be
used anywhere. If it hasn't, then why can't we keep the current
(Emacs 26) solution?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 30 Dec 2018 06:46:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Ulrich Mueller wrote:
> So you're saying that on systems that don't have XDG_RUNTIME_DIR,
> placing the socket under TMPDIR is fine? Because I don't understand
> that argument. If TMPDIR has security problem, then it shouldn't be
> used anywhere. If it hasn't, then why can't we keep the current
> (Emacs 26) solution?
Because we're not absolutists. On older systems that do not have adequate
provisions for security, Emacs does the best it can: that's better than not
doing anything, and people who run older, less-secure systems are likely to not
care all that much about security anyway so this is OK. On newer systems that
are more secure, though, Emacs can be more secure.
This is not anything new. In the bad old days when /tmp wasn't sticky, Emacs was
less secure with temporary files, just like everyone else was. That didn't mean
that Emacs should never have used temporary files.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 30 Dec 2018 06:48:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Ulrich Mueller wrote:
> The only problem I see is that it would leave a stale socket file
> behind, when Emacs is not properly terminated. That file would be
> deleted/replaced the next time an Emacs server is started.
>
> I guess in the typical use case we are talking about a single inode.
> If the home directory is NFS mounted it may be one inode per machine.
> I think that's a small price to pay, for a solution that would be both
> very simple, would be available on all systems, and won't suffer from
> security issues.
If we're talking NFS, we will indeed have security issues, not to mention
problems with deleting or replacing files. I can't count the number of times
I've seen messages like "NFS server not responding still trying".
The TCP case is already documented as being undesirable, and this is partly due
to security concerns. We shouldn't inflict its problems on the more-usual local
case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 20 Jan 2019 18:00:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 33847 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sun, 30 Dec 2018, Paul Eggert wrote:
> Because we're not absolutists. On older systems that do not have
> adequate provisions for security, Emacs does the best it can: that's
> better than not doing anything, and people who run older, less-secure
> systems are likely to not care all that much about security anyway so
> this is OK. On newer systems that are more secure, though, Emacs can
> be more secure.
Since there doesn't seem to be any progress here, please find below
the patch that I am using since some time.
From f8d87a0a89b91c120935bd5be802604b2c749767 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm <at> gentoo.org>
Date: Sun, 20 Jan 2019 18:48:45 +0100
Subject: [PATCH] Add a fallback for the socket location in emacsclient
(bug#33847)
* lib-src/emacsclient.c (set_local_socket): Fall back to TMPDIR
if the socket is not found under XDG_RUNTIME_DIR.
---
lib-src/emacsclient.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c
index f476840898..27b945133e 100644
--- a/lib-src/emacsclient.c
+++ b/lib-src/emacsclient.c
@@ -1356,6 +1356,7 @@ set_local_socket (char const *server_name)
enum { socknamesize = sizeof server.un.sun_path };
int tmpdirlen = -1;
int socknamelen = -1;
+ int sock_status = -1;
uid_t uid = geteuid ();
if (strchr (server_name, '/')
@@ -1366,9 +1367,15 @@ set_local_socket (char const *server_name)
/* socket_name is a file name component. */
char const *xdg_runtime_dir = egetenv ("XDG_RUNTIME_DIR");
if (xdg_runtime_dir)
- socknamelen = snprintf (sockname, socknamesize, "%s/emacs/%s",
- xdg_runtime_dir, server_name);
- else
+ {
+ socknamelen = snprintf (sockname, socknamesize, "%s/emacs/%s",
+ xdg_runtime_dir, server_name);
+ /* Check if sockname is valid and if the socket exists. */
+ if (0 <= socknamelen && socknamelen < socknamesize)
+ sock_status = socket_status (sockname, uid);
+ }
+
+ if (sock_status)
{
char const *tmpdir = egetenv ("TMPDIR");
if (tmpdir)
@@ -1399,7 +1406,9 @@ set_local_socket (char const *server_name)
}
/* See if the socket exists, and if it's owned by us. */
- int sock_status = socket_status (sockname, uid);
+ if (sock_status)
+ sock_status = socket_status (sockname, uid);
+
if (sock_status)
{
/* Failing that, see if LOGNAME or USER exist and differ from
--
2.19.1
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 10 Feb 2019 08:39:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 33847 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sun, 20 Jan 2019, Ulrich Mueller wrote:
> Since there doesn't seem to be any progress here, please find below
> the patch that I am using since some time.
Does the absence of any reply (neither here nor on emacs-devel) mean
that it is o.k. to push this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 10 Feb 2019 09:49:02 GMT)
Full text and
rfc822 format available.
Message #65 received at submit <at> debbugs.gnu.org (full text, mbox):
On February 10, 2019 10:37:46 AM GMT+02:00, Ulrich Mueller <ulm <at> gentoo.org> wrote:
> >>>>> On Sun, 20 Jan 2019, Ulrich Mueller wrote:
>
> > Since there doesn't seem to be any progress here, please find below
> > the patch that I am using since some time.
>
> Does the absence of any reply (neither here nor on emacs-devel) mean
> that it is o.k. to push this?
Sorry, no. It means you should wait for an explicit agreement to your proposed patch, and perhaps ping Paul to review it. Especially since Paul objected to the idea on which your patch is based.
I apologize for our slow turnaround times wrt this issue.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 10 Feb 2019 09:49:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 27 Apr 2019 01:42:03 GMT)
Full text and
rfc822 format available.
Message #71 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Whatever the solution, please describe the behavior in man (1) emacsclient. Even TMPDIR is *not* written. Please, avoid the unseeable!
# Hi, Ulrich, thanks for your long time Gentoo emacs development. :)
Thank you very much Paul, Eli, and last but not least, RMS. (Wow) Best wishes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 27 Apr 2019 07:57:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 27 Apr 2019 10:41:08 +0900 (JST)
> From: Teika Kazura <teika <at> gmx.com>
>
> Whatever the solution, please describe the behavior in man (1) emacsclient. Even TMPDIR is *not* written. Please, avoid the unseeable!
Our main documentation is the Emacs User manual, not the man pages. I
suggest to look in the manual when you need to know what emacsclient
does.
Of course, I don't object to extending the man page as well.
> # Hi, Ulrich, thanks for your long time Gentoo emacs development. :)
>
> Thank you very much Paul, Eli, and last but not least, RMS. (Wow) Best wishes.
You are welcome.
Added tag(s) patch.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Thu, 13 Aug 2020 12:16:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Wed, 19 Aug 2020 11:06:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > Since there doesn't seem to be any progress here, please find below
>> > the patch that I am using since some time.
>>
>> Does the absence of any reply (neither here nor on emacs-devel) mean
>> that it is o.k. to push this?
>
> Sorry, no. It means you should wait for an explicit agreement to your
> proposed patch, and perhaps ping Paul to review it. Especially since
> Paul objected to the idea on which your patch is based.
>
> I apologize for our slow turnaround times wrt this issue.
This was a year and a half ago, and other users have also reported
problem here (which, if I understand things correctly, this patch
fixes).
I've just skimmed the thread, but the patch seems to me like a
reasonable thing to add to make these use cases work again.
Paul?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Fri, 21 Aug 2020 21:29:01 GMT)
Full text and
rfc822 format available.
Message #82 received at 33847 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 8/19/20 4:05 AM, Lars Ingebrigtsen wrote:
> I've just skimmed the thread, but the patch seems to me like a
> reasonable thing to add to make these use cases work again.
Although that patch would makes the use cases work again, it does so at the
expense of security in XDG environments, because it opens holes allowing symlink
attacks. You log in in an XDG environment, you don't run Emacs server, you run
emacsclient - and the attacker's symlink in /tmp (or whatever) causes
emacsclient to send garbage to some other socket of yours that may not be
prepared for the garbage.
I spent quite a bit of time looking into this and came up with the attached
proposed patch which should make the use cases work again without opening
security holes. This patch fixes some other bugs that I noticed while I was in
the area.
These use cases continue to be dubious security-wise (for other programs as well
as for Emacs), but if they're popular then this patch should help people avoid
shooting themselves in the foot quite so often.
[0001-Redo-emacsclient-socket-symlink-attack-checking.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 22 Aug 2020 07:25:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 33847 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 21 Aug 2020, Paul Eggert wrote:
> These use cases continue to be dubious security-wise (for other
> programs as well as for Emacs), but if they're popular then this patch
> should help people avoid shooting themselves in the foot quite so
> often.
Looks complicated.
What about my earlier suggestion to avoid both /tmp and XDG_RUNTIME_DIR,
but create the socket in a subdir of user-emacs-directory instead?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 22 Aug 2020 07:34:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 33847 <at> debbugs.gnu.org (full text, mbox):
On Aug 22 2020, Ulrich Mueller wrote:
> What about my earlier suggestion to avoid both /tmp and XDG_RUNTIME_DIR,
> but create the socket in a subdir of user-emacs-directory instead?
user-emacs-directory may be a shared directory, causing clashes when
Emacs is run simultanously on different hosts.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 22 Aug 2020 07:46:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 33847 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sat, 22 Aug 2020, Andreas Schwab wrote:
> user-emacs-directory may be a shared directory, causing clashes when
> Emacs is run simultanously on different hosts.
Is that really a problem for local sockets? Also, it should be trivial
to disambiguate it using the hostname.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 22 Aug 2020 08:01:01 GMT)
Full text and
rfc822 format available.
Message #94 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> Cc: 33847 <at> debbugs.gnu.org, Ulrich Mueller <ulm <at> gentoo.org>,
> Teika Kazura <teika <at> gmx.com>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 21 Aug 2020 14:28:36 -0700
>
> I spent quite a bit of time looking into this and came up with the attached
> proposed patch which should make the use cases work again without opening
> security holes. This patch fixes some other bugs that I noticed while I was in
> the area.
This patch will almost certainly break w32, so please don't install
without a heads-up and some time left to adapt.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 22 Aug 2020 08:01:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> From: Ulrich Mueller <ulm <at> gentoo.org>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>,
> 33847 <at> debbugs.gnu.org, Ulrich Mueller <ulm <at> gentoo.org>, Teika Kazura
> <teika <at> gmx.com>
> Date: Sat, 22 Aug 2020 09:24:39 +0200
>
> >>>>> On Fri, 21 Aug 2020, Paul Eggert wrote:
>
> > These use cases continue to be dubious security-wise (for other
> > programs as well as for Emacs), but if they're popular then this patch
> > should help people avoid shooting themselves in the foot quite so
> > often.
>
> Looks complicated.
The understatement of the year, I'd say ;-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 22 Aug 2020 17:52:01 GMT)
Full text and
rfc822 format available.
Message #100 received at 33847 <at> debbugs.gnu.org (full text, mbox):
On 8/22/20 12:24 AM, Ulrich Mueller wrote:
>>>>>> On Fri, 21 Aug 2020, Paul Eggert wrote:
>
>> These use cases continue to be dubious security-wise (for other
>> programs as well as for Emacs), but if they're popular then this patch
>> should help people avoid shooting themselves in the foot quite so
>> often.
>
> Looks complicated.
Yes. It's complicated partly because it fixes longstanding obscure security bugs
in the /tmp handling code. These bugs should be fixed anyway, regardless of what
we do about XDG_RUNTIME_DIR. With some effort I could break it into two patches
but I'd rather not spend the effort - I already have spent more time in this
obscure but security-relevant area than I'd like.
> What about my earlier suggestion to avoid both /tmp and XDG_RUNTIME_DIR,
> but create the socket in a subdir of user-emacs-directory instead?
This would be worse for several reasons: you'd need to disambiguate via
hostname, you'd need to guarantee hostnames are unique, you'd have problems when
NFS is flaky or hanging in your home directory, and you'd need to deal with
socket files that survive OS crashes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 22 Aug 2020 17:56:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 33847 <at> debbugs.gnu.org (full text, mbox):
On 8/22/20 12:59 AM, Eli Zaretskii wrote:
> This patch will almost certainly break w32
How so? The emacsclient.c changes are almost all inside "#ifdef
SOCKETS_IN_FILE_SYSTEM", and that's defined only if WINDOWSNT is not defined.
Outside that #ifdef, only "#include <acl.h>" seems relevant and src/fileio.c
already does that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 22 Aug 2020 18:31:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 33847 <at> debbugs.gnu.org, ulm <at> gentoo.org, teika <at> gmx.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 22 Aug 2020 10:55:16 -0700
>
> Outside that #ifdef, only "#include <acl.h>" seems relevant and src/fileio.c
> already does that.
The acl stuff in Emacs for w32 is implemented in w32.c.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 22 Aug 2020 21:21:01 GMT)
Full text and
rfc822 format available.
Message #109 received at 33847 <at> debbugs.gnu.org (full text, mbox):
On 8/22/20 11:30 AM, Eli Zaretskii wrote:
>> Outside that #ifdef, only "#include <acl.h>" seems relevant and src/fileio.c
>> already does that.
> The acl stuff in Emacs for w32 is implemented in w32.c.
If WINDOWSNT is defined then the patched emacsclient.c never uses any of the acl
stuff. It doesn't even link to it; it's all ifdeffed out. So what problems do
you anticipate?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 23 Aug 2020 05:42:01 GMT)
Full text and
rfc822 format available.
Message #112 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 33847 <at> debbugs.gnu.org, ulm <at> gentoo.org, teika <at> gmx.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 22 Aug 2020 14:20:35 -0700
>
> On 8/22/20 11:30 AM, Eli Zaretskii wrote:
> >> Outside that #ifdef, only "#include <acl.h>" seems relevant and src/fileio.c
> >> already does that.
> > The acl stuff in Emacs for w32 is implemented in w32.c.
>
> If WINDOWSNT is defined then the patched emacsclient.c never uses any of the acl
> stuff. It doesn't even link to it; it's all ifdeffed out. So what problems do
> you anticipate?
I said "almost" because I wasn't 110% sure. Maybe I was mistaken, and
there will be no changes; all I ask is a heads-up to allow me to study
the patch more thoroughly and test it, that's all.
Forcibly Merged 33847 41707.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 14 Sep 2020 15:04:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Thu, 22 Jul 2021 13:09:01 GMT)
Full text and
rfc822 format available.
Message #117 received at 33847 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> I said "almost" because I wasn't 110% sure. Maybe I was mistaken, and
> there will be no changes; all I ask is a heads-up to allow me to study
> the patch more thoroughly and test it, that's all.
This was the last post in this thread.
Paul's patch is pretty, er, long, but I've tested it a bit, and it
doesn't seem to break anything for me. But then again, there's a lot of
different setups in this area...
I've respun the patch for the current trunk. Can you give it a test and
see whether it works for you too?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
[client.patch (text/x-diff, inline)]
/usr/bin/patch: **** Only garbage was found in the patch input.
patching file admin/merge-gnulib
Hunk #1 FAILED at 33.
1 out of 1 hunk FAILED -- saving rejects to file /tmp/debbugs-gnu.rej
patching file lib-src/emacsclient.c
Hunk #3 succeeded at 1133 (offset -15 lines).
Hunk #4 succeeded at 1377 (offset -15 lines).
Hunk #5 succeeded at 1430 (offset -15 lines).
Hunk #6 succeeded at 1485 (offset -15 lines).
Hunk #7 succeeded at 1519 (offset -15 lines).
Hunk #8 succeeded at 1568 (offset -15 lines).
patching file lib/file-has-acl.c
patching file lib/gnulib.mk.in
Hunk #2 succeeded at 1789 (offset 112 lines).
patching file m4/gnulib-comp.m4
Hunk #1 succeeded at 89 (offset 2 lines).
Hunk #2 succeeded at 288 (offset 6 lines).
Hunk #3 succeeded at 1047 (offset 70 lines).
--- admin/merge-gnulib
+++ admin/merge-gnulib
@@ -33,7 +33,7 @@ GNULIB_MODULES=
crypto/md5-buffer crypto/sha1-buffer crypto/sha256-buffer crypto/sha512-buffer
d-type diffseq double-slash-root dtoastr dtotimespec dup2
environ execinfo explicit_bzero faccessat
- fchmodat fcntl fcntl-h fdopendir
+ fchmodat fcntl fcntl-h fdopendir file-has-acl
filemode filename filevercmp flexmember fpieee fstatat fsusage fsync futimens
getloadavg getopt-gnu getrandom gettime gettimeofday gitlog-to-changelog
ieee754-h ignore-value intprops largefile libgmp lstat
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Thu, 22 Jul 2021 16:47:01 GMT)
Full text and
rfc822 format available.
Message #120 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, teika <at> gmx.com,
> 33847 <at> debbugs.gnu.org, ulm <at> gentoo.org
> Date: Thu, 22 Jul 2021 15:08:39 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I said "almost" because I wasn't 110% sure. Maybe I was mistaken, and
> > there will be no changes; all I ask is a heads-up to allow me to study
> > the patch more thoroughly and test it, that's all.
>
> This was the last post in this thread.
>
> Paul's patch is pretty, er, long, but I've tested it a bit, and it
> doesn't seem to break anything for me. But then again, there's a lot of
> different setups in this area...
>
> I've respun the patch for the current trunk. Can you give it a test and
> see whether it works for you too?
Looks like you didn't attach the right patch?
Anyway, the main problem with the original patch is that it uses
Gnulib ACL module unconditionally. Gnulib's ACL module doesn't
support MS-Windows ACLs, so Emacs has its own emulation of the
relevant routines in w32.c. To make this emacsclient patch work on
MS-Windows one must either #ifdef away the emacsclient ACL code for
the WINDOWSNT build, or provide ACL emulation code in ntlib.c. Both
are non-trivial jobs that I didn't yet have time to do, sorry. I can
look into that during the following days if you show the right patch.
However, it sounds like Ulrich wasn't happy with this solution back
then, so perhaps we should first see that the problem still exists and
that everyone involved are okay with installing this, modulo minor
fixes?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Thu, 22 Jul 2021 17:06:02 GMT)
Full text and
rfc822 format available.
Message #123 received at 33847 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Looks like you didn't attach the right patch?
Yup; 2nd attempt now.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
[client.patch (text/x-diff, inline)]
diff --git a/admin/merge-gnulib b/admin/merge-gnulib
index 1c8b442700..c12e83dd2f 100755
--- a/admin/merge-gnulib
+++ b/admin/merge-gnulib
@@ -33,7 +33,7 @@ GNULIB_MODULES=
crypto/md5-buffer crypto/sha1-buffer crypto/sha256-buffer crypto/sha512-buffer
d-type diffseq double-slash-root dtoastr dtotimespec dup2
environ execinfo explicit_bzero faccessat
- fchmodat fcntl fcntl-h fdopendir
+ fchmodat fcntl fcntl-h fdopendir file-has-acl
filemode filename filevercmp flexmember fpieee
free-posix fstatat fsusage fsync futimens
getloadavg getopt-gnu getrandom gettime gettimeofday gitlog-to-changelog
diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c
index 12ced4aadb..3972cbba45 100644
--- a/lib-src/emacsclient.c
+++ b/lib-src/emacsclient.c
@@ -80,6 +80,7 @@ Copyright (C) 1986-1987, 1994, 1999-2021 Free Software Foundation, Inc.
#include <sys/stat.h>
#include <unistd.h>
+#include <acl.h>
#include <filename.h>
#include <intprops.h>
#include <min-max.h>
@@ -91,6 +92,10 @@ Copyright (C) 1986-1987, 1994, 1999-2021 Free Software Foundation, Inc.
# pragma GCC diagnostic ignored "-Wformat-truncation=2"
#endif
+#ifndef O_PATH
+# define O_PATH O_SEARCH
+#endif
+
/* Name used to invoke this program. */
static char const *progname;
@@ -1128,24 +1133,74 @@ process_grouping (void)
#ifdef SOCKETS_IN_FILE_SYSTEM
-/* Return the file status of NAME, ordinarily a socket.
- It should be owned by UID. Return one of the following:
- >0 - 'stat' failed with this errno value
- -1 - isn't owned by us
- 0 - success: none of the above */
+/* A local socket address. The union avoids the need to cast. */
+union local_sockaddr
+{
+ struct sockaddr_un un;
+ struct sockaddr sa;
+};
+
+/* Relative to the directory DIRFD, connect the socket file named ADDR
+ to the socket S. Return 0 if successful, -1 if DIRFD is not
+ AT_FDCWD and DIRFD's permissions would allow a symlink attack, an
+ errno otherwise. */
static int
-socket_status (const char *name, uid_t uid)
+connect_socket (int dirfd, char const *addr, int s, uid_t uid)
{
- struct stat statbfr;
+ int sock_status = 0;
- if (stat (name, &statbfr) != 0)
- return errno;
+ union local_sockaddr server;
+ if (sizeof server.un.sun_path <= strlen (addr))
+ return ENAMETOOLONG;
+ server.un.sun_family = AF_UNIX;
+ strcpy (server.un.sun_path, addr);
- if (statbfr.st_uid != uid)
- return -1;
+ /* If -1, WDFD is not set yet. If nonnegative, WDFD is a file
+ descriptor for the initial working directory. Otherwise -1 - WDFD is
+ the error number for the initial working directory. */
+ static int wdfd = -1;
- return 0;
+ if (dirfd != AT_FDCWD)
+ {
+ /* Fail if DIRFD's permissions are bogus. */
+ struct stat st;
+ if (fstat (dirfd, &st) != 0)
+ return errno;
+ if (st.st_uid != uid || (st.st_mode & (S_IWGRP | S_IWOTH)))
+ return -1;
+
+ if (wdfd == -1)
+ {
+ /* Save the initial working directory. */
+ wdfd = open (".", O_PATH | O_CLOEXEC);
+ if (wdfd < 0)
+ wdfd = -1 - errno;
+ }
+ if (wdfd < 0)
+ return -1 - wdfd;
+ if (fchdir (dirfd) != 0)
+ return errno;
+
+ /* Fail if DIRFD has an ACL, which means its permissions are
+ almost surely bogus. */
+ int has_acl = file_has_acl (".", &st);
+ if (has_acl)
+ sock_status = has_acl < 0 ? errno : -1;
+ }
+
+ if (!sock_status)
+ sock_status = connect (s, &server.sa, sizeof server.un) == 0 ? 0 : errno;
+
+ /* Fail immediately if we cannot change back to the initial working
+ directory, as that can mess up the rest of execution. */
+ if (dirfd != AT_FDCWD && fchdir (wdfd) != 0)
+ {
+ message (true, "%s: .: %s\n", progname, strerror (errno));
+ exit (EXIT_FAILURE);
+ }
+
+ return sock_status;
}
@@ -1322,32 +1377,49 @@ act_on_signals (HSOCKET emacs_socket)
}
}
-/* Create in SOCKNAME (of size SOCKNAMESIZE) a name for a local socket.
- The first TMPDIRLEN bytes of SOCKNAME are already initialized to be
- the name of a temporary directory. Use UID and SERVER_NAME to
- concoct the name. Return the total length of the name if successful,
- -1 if it does not fit (and store a truncated name in that case).
- Fail if TMPDIRLEN is out of range. */
+enum { socknamesize = sizeof ((struct sockaddr_un *) NULL)->sun_path };
+
+/* Given a local socket S, create in *SOCKNAME a name for a local socket
+ and connect to that socket. The first TMPDIRLEN bytes of *SOCKNAME are
+ already initialized to be the name of a temporary directory.
+ Use UID and SERVER_NAME to concoct the name. Return 0 if
+ successful, -1 if the socket's parent directory is not safe, and an
+ errno if there is some other problem. */
static int
-local_sockname (char *sockname, int socknamesize, int tmpdirlen,
- uintmax_t uid, char const *server_name)
+local_sockname (int s, char sockname[socknamesize], int tmpdirlen,
+ uid_t uid, char const *server_name)
{
/* If ! (0 <= TMPDIRLEN && TMPDIRLEN < SOCKNAMESIZE) the truncated
temporary directory name is already in SOCKNAME, so nothing more
need be stored. */
- if (0 <= tmpdirlen)
- {
- int remaining = socknamesize - tmpdirlen;
- if (0 < remaining)
- {
- int suffixlen = snprintf (&sockname[tmpdirlen], remaining,
- "/emacs%"PRIuMAX"/%s", uid, server_name);
- if (0 <= suffixlen && suffixlen < remaining)
- return tmpdirlen + suffixlen;
- }
- }
- return -1;
+ if (! (0 <= tmpdirlen && tmpdirlen < socknamesize))
+ return ENAMETOOLONG;
+
+ /* Put the full address name into the buffer, since the caller might
+ need it for diagnostics. But don't overrun the buffer. */
+ uintmax_t uidmax = uid;
+ int emacsdirlen;
+ int suffixlen = snprintf (sockname + tmpdirlen, socknamesize - tmpdirlen,
+ "/emacs%"PRIuMAX"%n/%s", uidmax, &emacsdirlen,
+ server_name);
+ if (! (0 <= suffixlen && suffixlen < socknamesize - tmpdirlen))
+ return ENAMETOOLONG;
+
+ /* Make sure the address's parent directory is not a symlink and is
+ this user's directory and does not let others write to it; this
+ fends off some symlink attacks. To avoid races, keep the parent
+ directory open while checking. */
+ char *emacsdirend = sockname + tmpdirlen + emacsdirlen;
+ *emacsdirend = '\0';
+ int dir = openat (AT_FDCWD, sockname,
+ O_PATH | O_DIRECTORY | O_NOFOLLOW | O_CLOEXEC);
+ *emacsdirend = '/';
+ if (dir < 0)
+ return errno;
+ int sock_status = connect_socket (dir, server_name, s, uid);
+ close (dir);
+ return sock_status;
}
/* Create a local socket for SERVER_NAME and connect it to Emacs. If
@@ -1358,28 +1430,43 @@ local_sockname (char *sockname, int socknamesize, int tmpdirlen,
static HSOCKET
set_local_socket (char const *server_name)
{
- union {
- struct sockaddr_un un;
- struct sockaddr sa;
- } server = {{ .sun_family = AF_UNIX }};
+ union local_sockaddr server;
+ int sock_status;
char *sockname = server.un.sun_path;
- enum { socknamesize = sizeof server.un.sun_path };
int tmpdirlen = -1;
int socknamelen = -1;
uid_t uid = geteuid ();
bool tmpdir_used = false;
+ int s = cloexec_socket (AF_UNIX, SOCK_STREAM, 0);
+ if (s < 0)
+ {
+ message (true, "%s: can't create socket: %s\n",
+ progname, strerror (errno));
+ fail ();
+ }
if (strchr (server_name, '/')
|| (ISSLASH ('\\') && strchr (server_name, '\\')))
- socknamelen = snprintf (sockname, socknamesize, "%s", server_name);
+ {
+ socknamelen = snprintf (sockname, socknamesize, "%s", server_name);
+ sock_status = (0 <= socknamelen && socknamelen < socknamesize
+ ? connect_socket (AT_FDCWD, sockname, s, 0)
+ : ENAMETOOLONG);
+ }
else
{
/* socket_name is a file name component. */
+ sock_status = ENOENT;
char const *xdg_runtime_dir = egetenv ("XDG_RUNTIME_DIR");
if (xdg_runtime_dir)
- socknamelen = snprintf (sockname, socknamesize, "%s/emacs/%s",
- xdg_runtime_dir, server_name);
- else
+ {
+ socknamelen = snprintf (sockname, socknamesize, "%s/emacs/%s",
+ xdg_runtime_dir, server_name);
+ sock_status = (0 <= socknamelen && socknamelen < socknamesize
+ ? connect_socket (AT_FDCWD, sockname, s, 0)
+ : ENAMETOOLONG);
+ }
+ if (sock_status == ENOENT)
{
char const *tmpdir = egetenv ("TMPDIR");
if (tmpdir)
@@ -1398,23 +1485,24 @@ set_local_socket (char const *server_name)
if (tmpdirlen < 0)
tmpdirlen = snprintf (sockname, socknamesize, "/tmp");
}
- socknamelen = local_sockname (sockname, socknamesize, tmpdirlen,
+ sock_status = local_sockname (s, sockname, tmpdirlen,
uid, server_name);
tmpdir_used = true;
}
}
- if (! (0 <= socknamelen && socknamelen < socknamesize))
+ if (sock_status == 0)
+ return s;
+
+ if (sock_status == ENAMETOOLONG)
{
message (true, "%s: socket-name %s... too long\n", progname, sockname);
fail ();
}
- /* See if the socket exists, and if it's owned by us. */
- int sock_status = socket_status (sockname, uid);
- if (sock_status)
+ if (tmpdir_used)
{
- /* Failing that, see if LOGNAME or USER exist and differ from
+ /* See whether LOGNAME or USER exist and differ from
our euid. If so, look for a socket based on the UID
associated with the name. This is reminiscent of the logic
that init_editfns uses to set the global Vuser_full_name. */
@@ -1431,48 +1519,26 @@ set_local_socket (char const *server_name)
if (pw && pw->pw_uid != uid)
{
/* We're running under su, apparently. */
- socknamelen = local_sockname (sockname, socknamesize, tmpdirlen,
+ sock_status = local_sockname (s, sockname, tmpdirlen,
pw->pw_uid, server_name);
- if (socknamelen < 0)
+ if (sock_status == 0)
+ return s;
+ if (sock_status == ENAMETOOLONG)
{
message (true, "%s: socket-name %s... too long\n",
progname, sockname);
exit (EXIT_FAILURE);
}
-
- sock_status = socket_status (sockname, uid);
}
}
}
- if (sock_status == 0)
- {
- HSOCKET s = cloexec_socket (AF_UNIX, SOCK_STREAM, 0);
- if (s < 0)
- {
- message (true, "%s: socket: %s\n", progname, strerror (errno));
- return INVALID_SOCKET;
- }
- if (connect (s, &server.sa, sizeof server.un) != 0)
- {
- message (true, "%s: connect: %s\n", progname, strerror (errno));
- CLOSE_SOCKET (s);
- return INVALID_SOCKET;
- }
-
- struct stat connect_stat;
- if (fstat (s, &connect_stat) != 0)
- sock_status = errno;
- else if (connect_stat.st_uid == uid)
- return s;
- else
- sock_status = -1;
-
- CLOSE_SOCKET (s);
- }
+ close (s);
- if (sock_status < 0)
- message (true, "%s: Invalid socket owner\n", progname);
+ if (sock_status == -1)
+ message (true,
+ "%s: Invalid permissions on parent directory of socket: %s\n",
+ progname, sockname);
else if (sock_status == ENOENT)
{
if (tmpdir_used)
@@ -1502,7 +1568,7 @@ set_local_socket (char const *server_name)
}
}
else
- message (true, "%s: can't stat %s: %s\n",
+ message (true, "%s: can't connect to %s: %s\n",
progname, sockname, strerror (sock_status));
return INVALID_SOCKET;
diff --git a/lib/file-has-acl.c b/lib/file-has-acl.c
new file mode 100644
index 0000000000..c667ae9d24
--- /dev/null
+++ b/lib/file-has-acl.c
@@ -0,0 +1,510 @@
+/* Test whether a file has a nontrivial ACL. -*- coding: utf-8 -*-
+
+ Copyright (C) 2002-2003, 2005-2020 Free Software Foundation, Inc.
+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+ Written by Paul Eggert, Andreas Grünbacher, and Bruno Haible. */
+
+/* Without this pragma, gcc 4.7.0 20120126 may suggest that the
+ file_has_acl function might be candidate for attribute 'const' */
+#if (__GNUC__ == 4 && 6 <= __GNUC_MINOR__) || 4 < __GNUC__
+# pragma GCC diagnostic ignored "-Wsuggest-attribute=const"
+#endif
+
+#include <config.h>
+
+#include "acl.h"
+
+#include "acl-internal.h"
+
+#if GETXATTR_WITH_POSIX_ACLS
+# include <sys/xattr.h>
+# include <linux/xattr.h>
+#endif
+
+/* Return 1 if NAME has a nontrivial access control list,
+ 0 if ACLs are not supported, or if NAME has no or only a base ACL,
+ and -1 (setting errno) on error. Note callers can determine
+ if ACLs are not supported as errno is set in that case also.
+ SB must be set to the stat buffer of NAME,
+ obtained through stat() or lstat(). */
+
+int
+file_has_acl (char const *name, struct stat const *sb)
+{
+#if USE_ACL
+ if (! S_ISLNK (sb->st_mode))
+ {
+
+# if GETXATTR_WITH_POSIX_ACLS
+
+ ssize_t ret;
+
+ ret = getxattr (name, XATTR_NAME_POSIX_ACL_ACCESS, NULL, 0);
+ if (ret < 0 && errno == ENODATA)
+ ret = 0;
+ else if (ret > 0)
+ return 1;
+
+ if (ret == 0 && S_ISDIR (sb->st_mode))
+ {
+ ret = getxattr (name, XATTR_NAME_POSIX_ACL_DEFAULT, NULL, 0);
+ if (ret < 0 && errno == ENODATA)
+ ret = 0;
+ else if (ret > 0)
+ return 1;
+ }
+
+ if (ret < 0)
+ return - acl_errno_valid (errno);
+ return ret;
+
+# elif HAVE_ACL_GET_FILE
+
+ /* POSIX 1003.1e (draft 17 -- abandoned) specific version. */
+ /* Linux, FreeBSD, Mac OS X, IRIX, Tru64, Cygwin >= 2.5 */
+ int ret;
+
+ if (HAVE_ACL_EXTENDED_FILE) /* Linux */
+ {
+ /* On Linux, acl_extended_file is an optimized function: It only
+ makes two calls to getxattr(), one for ACL_TYPE_ACCESS, one for
+ ACL_TYPE_DEFAULT. */
+ ret = acl_extended_file (name);
+ }
+ else /* FreeBSD, Mac OS X, IRIX, Tru64, Cygwin >= 2.5 */
+ {
+# if HAVE_ACL_TYPE_EXTENDED /* Mac OS X */
+ /* On Mac OS X, acl_get_file (name, ACL_TYPE_ACCESS)
+ and acl_get_file (name, ACL_TYPE_DEFAULT)
+ always return NULL / EINVAL. There is no point in making
+ these two useless calls. The real ACL is retrieved through
+ acl_get_file (name, ACL_TYPE_EXTENDED). */
+ acl_t acl = acl_get_file (name, ACL_TYPE_EXTENDED);
+ if (acl)
+ {
+ ret = acl_extended_nontrivial (acl);
+ acl_free (acl);
+ }
+ else
+ ret = -1;
+# else /* FreeBSD, IRIX, Tru64, Cygwin >= 2.5 */
+ acl_t acl = acl_get_file (name, ACL_TYPE_ACCESS);
+ if (acl)
+ {
+ int saved_errno;
+
+ ret = acl_access_nontrivial (acl);
+ saved_errno = errno;
+ acl_free (acl);
+ errno = saved_errno;
+# if HAVE_ACL_FREE_TEXT /* Tru64 */
+ /* On OSF/1, acl_get_file (name, ACL_TYPE_DEFAULT) always
+ returns NULL with errno not set. There is no point in
+ making this call. */
+# else /* FreeBSD, IRIX, Cygwin >= 2.5 */
+ /* On Linux, FreeBSD, IRIX, acl_get_file (name, ACL_TYPE_ACCESS)
+ and acl_get_file (name, ACL_TYPE_DEFAULT) on a directory
+ either both succeed or both fail; it depends on the
+ file system. Therefore there is no point in making the second
+ call if the first one already failed. */
+ if (ret == 0 && S_ISDIR (sb->st_mode))
+ {
+ acl = acl_get_file (name, ACL_TYPE_DEFAULT);
+ if (acl)
+ {
+# ifdef __CYGWIN__ /* Cygwin >= 2.5 */
+ ret = acl_access_nontrivial (acl);
+ saved_errno = errno;
+ acl_free (acl);
+ errno = saved_errno;
+# else
+ ret = (0 < acl_entries (acl));
+ acl_free (acl);
+# endif
+ }
+ else
+ ret = -1;
+ }
+# endif
+ }
+ else
+ ret = -1;
+# endif
+ }
+ if (ret < 0)
+ return - acl_errno_valid (errno);
+ return ret;
+
+# elif HAVE_FACL && defined GETACL /* Solaris, Cygwin < 2.5, not HP-UX */
+
+# if defined ACL_NO_TRIVIAL
+
+ /* Solaris 10 (newer version), which has additional API declared in
+ <sys/acl.h> (acl_t) and implemented in libsec (acl_set, acl_trivial,
+ acl_fromtext, ...). */
+ return acl_trivial (name);
+
+# else /* Solaris, Cygwin, general case */
+
+ /* Solaris 2.5 through Solaris 10, Cygwin, and contemporaneous versions
+ of Unixware. The acl() call returns the access and default ACL both
+ at once. */
+ {
+ /* Initially, try to read the entries into a stack-allocated buffer.
+ Use malloc if it does not fit. */
+ enum
+ {
+ alloc_init = 4000 / sizeof (aclent_t), /* >= 3 */
+ alloc_max = MIN (INT_MAX, SIZE_MAX / sizeof (aclent_t))
+ };
+ aclent_t buf[alloc_init];
+ size_t alloc = alloc_init;
+ aclent_t *entries = buf;
+ aclent_t *malloced = NULL;
+ int count;
+
+ for (;;)
+ {
+ count = acl (name, GETACL, alloc, entries);
+ if (count < 0 && errno == ENOSPC)
+ {
+ /* Increase the size of the buffer. */
+ free (malloced);
+ if (alloc > alloc_max / 2)
+ {
+ errno = ENOMEM;
+ return -1;
+ }
+ alloc = 2 * alloc; /* <= alloc_max */
+ entries = malloced =
+ (aclent_t *) malloc (alloc * sizeof (aclent_t));
+ if (entries == NULL)
+ {
+ errno = ENOMEM;
+ return -1;
+ }
+ continue;
+ }
+ break;
+ }
+ if (count < 0)
+ {
+ if (errno == ENOSYS || errno == ENOTSUP)
+ ;
+ else
+ {
+ int saved_errno = errno;
+ free (malloced);
+ errno = saved_errno;
+ return -1;
+ }
+ }
+ else if (count == 0)
+ ;
+ else
+ {
+ /* Don't use MIN_ACL_ENTRIES: It's set to 4 on Cygwin, but Cygwin
+ returns only 3 entries for files with no ACL. But this is safe:
+ If there are more than 4 entries, there cannot be only the
+ "user::", "group::", "other:", and "mask:" entries. */
+ if (count > 4)
+ {
+ free (malloced);
+ return 1;
+ }
+
+ if (acl_nontrivial (count, entries))
+ {
+ free (malloced);
+ return 1;
+ }
+ }
+ free (malloced);
+ }
+
+# ifdef ACE_GETACL
+ /* Solaris also has a different variant of ACLs, used in ZFS and NFSv4
+ file systems (whereas the other ones are used in UFS file systems). */
+ {
+ /* Initially, try to read the entries into a stack-allocated buffer.
+ Use malloc if it does not fit. */
+ enum
+ {
+ alloc_init = 4000 / sizeof (ace_t), /* >= 3 */
+ alloc_max = MIN (INT_MAX, SIZE_MAX / sizeof (ace_t))
+ };
+ ace_t buf[alloc_init];
+ size_t alloc = alloc_init;
+ ace_t *entries = buf;
+ ace_t *malloced = NULL;
+ int count;
+
+ for (;;)
+ {
+ count = acl (name, ACE_GETACL, alloc, entries);
+ if (count < 0 && errno == ENOSPC)
+ {
+ /* Increase the size of the buffer. */
+ free (malloced);
+ if (alloc > alloc_max / 2)
+ {
+ errno = ENOMEM;
+ return -1;
+ }
+ alloc = 2 * alloc; /* <= alloc_max */
+ entries = malloced = (ace_t *) malloc (alloc * sizeof (ace_t));
+ if (entries == NULL)
+ {
+ errno = ENOMEM;
+ return -1;
+ }
+ continue;
+ }
+ break;
+ }
+ if (count < 0)
+ {
+ if (errno == ENOSYS || errno == EINVAL)
+ ;
+ else
+ {
+ int saved_errno = errno;
+ free (malloced);
+ errno = saved_errno;
+ return -1;
+ }
+ }
+ else if (count == 0)
+ ;
+ else
+ {
+ /* In the old (original Solaris 10) convention:
+ If there are more than 3 entries, there cannot be only the
+ ACE_OWNER, ACE_GROUP, ACE_OTHER entries.
+ In the newer Solaris 10 and Solaris 11 convention:
+ If there are more than 6 entries, there cannot be only the
+ ACE_OWNER, ACE_GROUP, ACE_EVERYONE entries, each once with
+ NEW_ACE_ACCESS_ALLOWED_ACE_TYPE and once with
+ NEW_ACE_ACCESS_DENIED_ACE_TYPE. */
+ if (count > 6)
+ {
+ free (malloced);
+ return 1;
+ }
+
+ if (acl_ace_nontrivial (count, entries))
+ {
+ free (malloced);
+ return 1;
+ }
+ }
+ free (malloced);
+ }
+# endif
+
+ return 0;
+# endif
+
+# elif HAVE_GETACL /* HP-UX */
+
+ {
+ struct acl_entry entries[NACLENTRIES];
+ int count;
+
+ count = getacl (name, NACLENTRIES, entries);
+
+ if (count < 0)
+ {
+ /* ENOSYS is seen on newer HP-UX versions.
+ EOPNOTSUPP is typically seen on NFS mounts.
+ ENOTSUP was seen on Quantum StorNext file systems (cvfs). */
+ if (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTSUP)
+ ;
+ else
+ return -1;
+ }
+ else if (count == 0)
+ return 0;
+ else /* count > 0 */
+ {
+ if (count > NACLENTRIES)
+ /* If NACLENTRIES cannot be trusted, use dynamic memory
+ allocation. */
+ abort ();
+
+ /* If there are more than 3 entries, there cannot be only the
+ (uid,%), (%,gid), (%,%) entries. */
+ if (count > 3)
+ return 1;
+
+ {
+ struct stat statbuf;
+
+ if (stat (name, &statbuf) < 0)
+ return -1;
+
+ return acl_nontrivial (count, entries);
+ }
+ }
+ }
+
+# if HAVE_ACLV_H /* HP-UX >= 11.11 */
+
+ {
+ struct acl entries[NACLVENTRIES];
+ int count;
+
+ count = acl ((char *) name, ACL_GET, NACLVENTRIES, entries);
+
+ if (count < 0)
+ {
+ /* EOPNOTSUPP is seen on NFS in HP-UX 11.11, 11.23.
+ EINVAL is seen on NFS in HP-UX 11.31. */
+ if (errno == ENOSYS || errno == EOPNOTSUPP || errno == EINVAL)
+ ;
+ else
+ return -1;
+ }
+ else if (count == 0)
+ return 0;
+ else /* count > 0 */
+ {
+ if (count > NACLVENTRIES)
+ /* If NACLVENTRIES cannot be trusted, use dynamic memory
+ allocation. */
+ abort ();
+
+ /* If there are more than 4 entries, there cannot be only the
+ four base ACL entries. */
+ if (count > 4)
+ return 1;
+
+ return aclv_nontrivial (count, entries);
+ }
+ }
+
+# endif
+
+# elif HAVE_ACLX_GET && defined ACL_AIX_WIP /* AIX */
+
+ acl_type_t type;
+ char aclbuf[1024];
+ void *acl = aclbuf;
+ size_t aclsize = sizeof (aclbuf);
+ mode_t mode;
+
+ for (;;)
+ {
+ /* The docs say that type being 0 is equivalent to ACL_ANY, but it
+ is not true, in AIX 5.3. */
+ type.u64 = ACL_ANY;
+ if (aclx_get (name, 0, &type, aclbuf, &aclsize, &mode) >= 0)
+ break;
+ if (errno == ENOSYS)
+ return 0;
+ if (errno != ENOSPC)
+ {
+ if (acl != aclbuf)
+ {
+ int saved_errno = errno;
+ free (acl);
+ errno = saved_errno;
+ }
+ return -1;
+ }
+ aclsize = 2 * aclsize;
+ if (acl != aclbuf)
+ free (acl);
+ acl = malloc (aclsize);
+ if (acl == NULL)
+ {
+ errno = ENOMEM;
+ return -1;
+ }
+ }
+
+ if (type.u64 == ACL_AIXC)
+ {
+ int result = acl_nontrivial ((struct acl *) acl);
+ if (acl != aclbuf)
+ free (acl);
+ return result;
+ }
+ else if (type.u64 == ACL_NFS4)
+ {
+ int result = acl_nfs4_nontrivial ((nfs4_acl_int_t *) acl);
+ if (acl != aclbuf)
+ free (acl);
+ return result;
+ }
+ else
+ {
+ /* A newer type of ACL has been introduced in the system.
+ We should better support it. */
+ if (acl != aclbuf)
+ free (acl);
+ errno = EINVAL;
+ return -1;
+ }
+
+# elif HAVE_STATACL /* older AIX */
+
+ union { struct acl a; char room[4096]; } u;
+
+ if (statacl ((char *) name, STX_NORMAL, &u.a, sizeof (u)) < 0)
+ return -1;
+
+ return acl_nontrivial (&u.a);
+
+# elif HAVE_ACLSORT /* NonStop Kernel */
+
+ {
+ struct acl entries[NACLENTRIES];
+ int count;
+
+ count = acl ((char *) name, ACL_GET, NACLENTRIES, entries);
+
+ if (count < 0)
+ {
+ if (errno == ENOSYS || errno == ENOTSUP)
+ ;
+ else
+ return -1;
+ }
+ else if (count == 0)
+ return 0;
+ else /* count > 0 */
+ {
+ if (count > NACLENTRIES)
+ /* If NACLENTRIES cannot be trusted, use dynamic memory
+ allocation. */
+ abort ();
+
+ /* If there are more than 4 entries, there cannot be only the
+ four base ACL entries. */
+ if (count > 4)
+ return 1;
+
+ return acl_nontrivial (count, entries);
+ }
+ }
+
+# endif
+ }
+#endif
+
+ return 0;
+}
diff --git a/lib/gnulib.mk.in b/lib/gnulib.mk.in
index 07736f9b8b..0b9aaf6d9e 100644
--- a/lib/gnulib.mk.in
+++ b/lib/gnulib.mk.in
@@ -98,6 +98,7 @@
# fcntl \
# fcntl-h \
# fdopendir \
+# file-has-acl \
# filemode \
# filename \
# filevercmp \
@@ -1788,6 +1789,16 @@ EXTRA_libgnu_a_SOURCES += fdopendir.c
endif
## end gnulib module fdopendir
+## begin gnulib module file-has-acl
+ifeq (,$(OMIT_GNULIB_MODULE_file-has-acl))
+
+libgnu_a_SOURCES += file-has-acl.c
+
+EXTRA_DIST += acl-internal.h
+
+endif
+## end gnulib module file-has-acl
+
## begin gnulib module filemode
ifeq (,$(OMIT_GNULIB_MODULE_filemode))
diff --git a/m4/gnulib-comp.m4 b/m4/gnulib-comp.m4
index cd6f7b4bbd..05e7faa993 100644
--- a/m4/gnulib-comp.m4
+++ b/m4/gnulib-comp.m4
@@ -89,6 +89,7 @@ AC_DEFUN
# Code from module fcntl:
# Code from module fcntl-h:
# Code from module fdopendir:
+ # Code from module file-has-acl:
# Code from module filemode:
# Code from module filename:
# Code from module filevercmp:
@@ -287,6 +288,7 @@ AC_DEFUN
fi
gl_DIRENT_MODULE_INDICATOR([fdopendir])
gl_MODULE_INDICATOR([fdopendir])
+ gl_FILE_HAS_ACL
gl_FILEMODE
AC_C_FLEXIBLE_ARRAY_MEMBER
gl_FUNC_FPENDING
@@ -1045,6 +1047,7 @@ AC_DEFUN
lib/fcntl.c
lib/fcntl.in.h
lib/fdopendir.c
+ lib/file-has-acl.c
lib/filemode.c
lib/filemode.h
lib/filename.h
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Thu, 22 Jul 2021 17:31:01 GMT)
Full text and
rfc822 format available.
Message #126 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eggert <at> cs.ucla.edu, teika <at> gmx.com, 33847 <at> debbugs.gnu.org, ulm <at> gentoo.org
> Date: Thu, 22 Jul 2021 19:05:11 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Looks like you didn't attach the right patch?
>
> Yup; 2nd attempt now.
Thanks.
It looks like the w32-related aspect of this is easier to resolve than
I originally thought, because almost all of the changes are in the
SOCKETS_IN_FILE_SYSTEM part, which is not compiled for the MS-Windows
build. The only potential issues I spotted are:
> --- a/lib-src/emacsclient.c
> +++ b/lib-src/emacsclient.c
> @@ -80,6 +80,7 @@ Copyright (C) 1986-1987, 1994, 1999-2021 Free Software Foundation, Inc.
> #include <sys/stat.h>
> #include <unistd.h>
>
> +#include <acl.h> <<<<<<<<<<<<<<<<<<<<<<<<<<<
> #include <filename.h>
> #include <intprops.h>
> #include <min-max.h>
We cannot unconditionally include acl.h on MS-Windows, so this has to
be #ifdef'ed away.
> @@ -91,6 +92,10 @@ Copyright (C) 1986-1987, 1994, 1999-2021 Free Software Foundation, Inc.
> # pragma GCC diagnostic ignored "-Wformat-truncation=2"
> #endif
>
> +#ifndef O_PATH
> +# define O_PATH O_SEARCH <<<<<<<<<<<<<<<<<<<<<<<<<
> +#endif
This is probably harmless, but I'd like to #ifdef it away as well.
> diff --git a/lib/gnulib.mk.in b/lib/gnulib.mk.in
> index 07736f9b8b..0b9aaf6d9e 100644
> --- a/lib/gnulib.mk.in
> +++ b/lib/gnulib.mk.in
> @@ -98,6 +98,7 @@
> # fcntl \
> # fcntl-h \
> # fdopendir \
> +# file-has-acl \
> # filemode \
> # filename \
> # filevercmp \
> @@ -1788,6 +1789,16 @@ EXTRA_libgnu_a_SOURCES += fdopendir.c
> endif
> ## end gnulib module fdopendir
>
> +## begin gnulib module file-has-acl
> +ifeq (,$(OMIT_GNULIB_MODULE_file-has-acl))
> +
> +libgnu_a_SOURCES += file-has-acl.c
> +
> +EXTRA_DIST += acl-internal.h
> +
> +endif
> +## end gnulib module file-has-acl
> +
> ## begin gnulib module filemode
> ifeq (,$(OMIT_GNULIB_MODULE_filemode))
>
We need to add stuff to nt/gnulib-cfg.mk to omit building the
file-has-acl.c file on MS-Windows. (I can do that after the rest is
installed.)
The only other worry is whether we indeed have ways to test this
thoroughly enough on Posix systems.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Thu, 22 Jul 2021 18:31:01 GMT)
Full text and
rfc822 format available.
Message #129 received at 33847 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 22 Jul 2021, Eli Zaretskii wrote:
> However, it sounds like Ulrich wasn't happy with this solution back
> then,
I don't think I said that. I was only surprised that the fix was so
complicated. :)
> so perhaps we should first see that the problem still exists and that
> everyone involved are okay with installing this, modulo minor fixes?
The problem still exists in the current master: If the server is started
in a non-XDG environment then it will create its socket in /tmp, and an
emacsclient started in an XDG environment won't find the socket.
In my original report I had suggested:
| - Have emacsclient fall back to TMPDIR as well when no socket is found
| under XDG_RUNTIME_DIR.
I have tested the patch at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33847;filename=client.patch;att=1;msg=123
and the client falls back to /tmp as it should.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Fri, 23 Jul 2021 11:32:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> +#include <acl.h> <<<<<<<<<<<<<<<<<<<<<<<<<<<
>> #include <filename.h>
>> #include <intprops.h>
>> #include <min-max.h>
>
> We cannot unconditionally include acl.h on MS-Windows, so this has to
> be #ifdef'ed away.
>> +#ifndef O_PATH
>> +# define O_PATH O_SEARCH <<<<<<<<<<<<<<<<<<<<<<<<<
>> +#endif
>
> This is probably harmless, but I'd like to #ifdef it away as well.
OK; I've now adjusted the patch with those two things...
> The only other worry is whether we indeed have ways to test this
> thoroughly enough on Posix systems.
... and that is indeed the major problem here -- this is an area where
it's very difficult to test all the use cases, and Emacs behaves
differently here on different systems.
I think the only realistic way to get some testing here is to just push
it to the trunk and see whether people report issues, unfortunately.
(The patch works fine on this Debian system, at least, and Ulrich
reports the same, so we have at least two systems it works on. :-))
So I'll push the patch and we'll see whether there's any fall-out...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 28.1, send any further explanations to
33847 <at> debbugs.gnu.org and Ulrich Mueller <ulm <at> gentoo.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 23 Jul 2021 11:35:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Fri, 23 Jul 2021 11:39:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> (The patch works fine on this Debian system, at least, and Ulrich
> reports the same, so we have at least two systems it works on. :-))
And I've now tested on Macos, too, and emacsclient still works there.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Fri, 23 Jul 2021 11:59:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eggert <at> cs.ucla.edu, teika <at> gmx.com, 33847 <at> debbugs.gnu.org, ulm <at> gentoo.org
> Date: Fri, 23 Jul 2021 13:31:35 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > The only other worry is whether we indeed have ways to test this
> > thoroughly enough on Posix systems.
>
> ... and that is indeed the major problem here -- this is an area where
> it's very difficult to test all the use cases, and Emacs behaves
> differently here on different systems.
>
> I think the only realistic way to get some testing here is to just push
> it to the trunk and see whether people report issues, unfortunately.
> (The patch works fine on this Debian system, at least, and Ulrich
> reports the same, so we have at least two systems it works on. :-))
>
> So I'll push the patch and we'll see whether there's any fall-out...
That's fine with me, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Fri, 23 Jul 2021 23:59:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 33847 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 7/23/21 4:38 AM, Lars Ingebrigtsen wrote:
> And I've now tested on Macos, too, and emacsclient still works there.
Thanks for reminding me about that old patch. Unfortunately it uses an
old version of the Gnulib ACL code, which means it'll miss a fix or two.
I suggest the attached patches instead. They update Emacs to use current
Gnulib (the first two patches) and then apply the same patch you sent,
except with current Gnulib code.
The first two patches are something we should be doing anyway, to bring
Emacs up-to-date on other Gnulib stuff. One thing worth putting into
NEWS is the new --disable-year2038 option to 'configure', which may be
useful for the next glibc release (for those people still running Emacs
on 32-bit GNU/Linux x86 or ARM).
You probably gotta run 'make bootstrap' after installing these patches.
Although I fixed the glitches Eli noted, the other Gnulib changes may
need further changes to Emacs's Microsoft-related code.
[0001-Update-from-Gnulib-by-running-admin-merge-gnulib.patch (text/x-patch, attachment)]
[0002-By-hand-fixes-for-update-from-Gnulib.patch (text/x-patch, attachment)]
[0003-Redo-emacsclient-socket-symlink-attack-checking.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 24 Jul 2021 06:25:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> Cc: teika <at> gmx.com, 33847 <at> debbugs.gnu.org, ulm <at> gentoo.org,
> Eli Zaretskii <eliz <at> gnu.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 23 Jul 2021 16:58:00 -0700
>
> On 7/23/21 4:38 AM, Lars Ingebrigtsen wrote:
> > And I've now tested on Macos, too, and emacsclient still works there.
>
> Thanks for reminding me about that old patch. Unfortunately it uses an
> old version of the Gnulib ACL code, which means it'll miss a fix or two.
> I suggest the attached patches instead. They update Emacs to use current
> Gnulib (the first two patches) and then apply the same patch you sent,
> except with current Gnulib code.
Phew! Talk about a hammer and a nail!..
> The first two patches are something we should be doing anyway, to bring
> Emacs up-to-date on other Gnulib stuff. One thing worth putting into
> NEWS is the new --disable-year2038 option to 'configure', which may be
> useful for the next glibc release (for those people still running Emacs
> on 32-bit GNU/Linux x86 or ARM).
Yes, but why in conjunction with this particular issue? What does
socket security have to do with 2038/32-bit time_t issue and the
64-bit file offsets issue?
> You probably gotta run 'make bootstrap' after installing these patches.
> Although I fixed the glitches Eli noted, the other Gnulib changes may
> need further changes to Emacs's Microsoft-related code.
Which of the Gnulib changes might need that, please?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 24 Jul 2021 07:49:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 33847 <at> debbugs.gnu.org (full text, mbox):
On 7/23/21 11:23 PM, Eli Zaretskii wrote:
> why in conjunction with this particular issue?
It's typically better to sync to a single coherent version of Gnulib,
than to take bits and pieces from different versions of Gnulib. That way
one needn't worry about version mismatch.
>> Although I fixed the glitches Eli noted, the other Gnulib changes may
>> need further changes to Emacs's Microsoft-related code.
>
> Which of the Gnulib changes might need that, please?
I said that more as boilerplate than as careful analysis. But in looking
at the patch more carefully, there may be issues in nt/gnulib-cfg.mk
where you have to set the following appropriately for MS-Windows:
OMIT_GNULIB_MODULE_realloc-gnu
OMIT_GNULIB_MODULE_realloc-posix
The realloc-posix module supplies a 'realloc' that conforms to POSIX
(i.e., it sets errno when it fails, and it refuses to allocate anything
larger than PTRDIFF_MAX in size).
The realloc-gnu module in addition makes sure that 'realloc' is
compatible with GNU realloc (i.e., realloc (NULL, 0) returns nonnull
when it succeeds).
The new file lib/realloc.c arranges for a replacement realloc on
platforms where realloc-posix and/or realloc-gnu discover that the
system realloc doesn't match glibc realloc in behavior.
The msdos directory may need to do something similar. Also, it may need
to change "GNULIB_" to "GL_GNULIB_" for identifiers like GNULIB_GETLOADAVG.
There may be other issues, but these are the ones that jump out at me.
Hmm, come to think of it, does Emacs already arrange to avoid the
problematic realloc behavior areas? If so, we can avoid using
realloc-gnu and realloc-posix, which would simplify the patch a bit.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 24 Jul 2021 08:27:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, teika <at> gmx.com, 33847 <at> debbugs.gnu.org, ulm <at> gentoo.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 24 Jul 2021 00:48:25 -0700
>
> On 7/23/21 11:23 PM, Eli Zaretskii wrote:
>
> > why in conjunction with this particular issue?
>
> It's typically better to sync to a single coherent version of Gnulib,
> than to take bits and pieces from different versions of Gnulib. That way
> one needn't worry about version mismatch.
Yes, but making changes in most/all Gnulib while fixing a minor issue
in a single auxiliary program is IMO too much, and stretches this
principle way beyond any reasonable limit. So I'd prefer to make
these Gnulib updates a separate changeset, if that's feasible.
> >> Although I fixed the glitches Eli noted, the other Gnulib changes may
> >> need further changes to Emacs's Microsoft-related code.
> >
> > Which of the Gnulib changes might need that, please?
>
> I said that more as boilerplate than as careful analysis. But in looking
> at the patch more carefully, there may be issues in nt/gnulib-cfg.mk
> where you have to set the following appropriately for MS-Windows:
>
> OMIT_GNULIB_MODULE_realloc-gnu
> OMIT_GNULIB_MODULE_realloc-posix
>
> The realloc-posix module supplies a 'realloc' that conforms to POSIX
> (i.e., it sets errno when it fails, and it refuses to allocate anything
> larger than PTRDIFF_MAX in size).
>
> The realloc-gnu module in addition makes sure that 'realloc' is
> compatible with GNU realloc (i.e., realloc (NULL, 0) returns nonnull
> when it succeeds).
>
> The new file lib/realloc.c arranges for a replacement realloc on
> platforms where realloc-posix and/or realloc-gnu discover that the
> system realloc doesn't match glibc realloc in behavior.
We cannot use these modules on MS-Windows because we have our private
implementation of malloc/realloc/free in w32heap.c. Any problems with
errno and return values for zero-sized allocations must be handled by
our own code there (we could borrow the ideas from Gnulib, of course).
> The msdos directory may need to do something similar.
That's a different port of Emacs and a different libc, so the results
are different.
> There may be other issues, but these are the ones that jump out at me.
Can you tell which Gnulib modules are affected by the new
"--disable-year2038" option? This might have direct effect on how
Emacs is built with mingw.org's MinGW (which is what I use), and in
general to the entire issue of supporting old 32-bit versions of
MS-Windows.
> Hmm, come to think of it, does Emacs already arrange to avoid the
> problematic realloc behavior areas? If so, we can avoid using
> realloc-gnu and realloc-posix, which would simplify the patch a bit.
How would Emacs arrange to avoid these problems? I could take a look
if I knew what I should look for.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 24 Jul 2021 10:12:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 33847 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> They update Emacs to use current Gnulib (the first two patches) and
> then apply the same patch you sent, except with current Gnulib code.
Just one note here -- I already applied and pushed that patch to Emacs
28, so I guess it'll either have to be reverted (and then reapplied from
your new patch), or the new patch has to be rebased.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 24 Jul 2021 19:38:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 33847 <at> debbugs.gnu.org (full text, mbox):
On 7/24/21 3:11 AM, Lars Ingebrigtsen wrote:
> Just one note here -- I already applied and pushed that patch to Emacs
> 28, so I guess it'll either have to be reverted (and then reapplied from
> your new patch), or the new patch has to be rebased.
No problem, I'll rebase it with Eli's comments in mind.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sat, 24 Jul 2021 23:33:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 33847 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> We cannot use these modules on MS-Windows because we have our private
> implementation of malloc/realloc/free in w32heap.c.
In looking into this, I noticed that our current approach has another
problem, because admin/merge-gnulib avoids Gnulib's malloc-posix module
so that the Emacs build procedure need not worry about Gnulib's malloc
interposition on MS-Windows. However, Gnulib relies on the POSIX malloc
spec in its own use of malloc, so malloc-posix should be present in
Emacs; this is for the benefit of some platforms that are neither GNU
nor MS-Windows.
What we should do is (A) have the Emacs tarball contain whatever Gnulib
memory-allocation modules Gnulib needs, (B) arrange for Gnulib's
memory-allocation modules to be inactive on MS-Windows, and (C) arrange
for Emacs's private implementation of malloc/realloc/free to be
GNU-compatible.
Proposed patches attached to do all this. Patch 4/4 is the one needing
most scrutiny, since it involves MS-Windows which I don't use.
Some context here. Gnulib's recent memory-allocation changes mostly deal
with sizes exceeding PTRDIFF_MAX, which is a no-no for obvious reasons
(POSIX will prohibit this in the next version, I think) and where Gnulib
assumes malloc etc. will fail. This is of practical concern mostly on
32-bit platforms (though there's a practical concern with calloc even on
64-bit platforms).
Similarly, the new year2038 Gnulib code is of practical concern only on
some 32-bit platforms (namely, GNU/Linux x86 and ARM).
> Can you tell which Gnulib modules are affected by the new
> "--disable-year2038" option?
No modules are affected by the --disable-year2038 option on MS-Windows.
The --disable-year2038 option has an effect only on 32-bit GNU/Linux x86
and ARM (glibc 2.34 and later). On these platforms, the option affects a
good many Gnulib modules as well as Emacs source code directly. This is
because the option affects anything that gets or sets a timestamp from
the OS. 'stat' syscalls, for example.
As I understand it, MS-Windows switched to 64-bit time_t back in 2005
(even on 32-bit platforms), and nowadays you have to explicitly request
32-bit time_t (does anybody do that when building Emacs? I hope not).
The --disable-year2038 option does not have any effect on MS-Windows,
because nobody has bothered to add support for that option on that
platform and I expect and hope that nobody ever will.
The only reason --disable-year2038 might be useful to Emacs is on
GNU/Linux x86 or ARM, if Emacs is linked to old libraries that require
time_t to be 32-bit in their ABI. Although I don't know of any such
libraries being used with Emacs, I haven't checked everything that Emacs
potentially links to, so there might be an issue there.
Any Emacs executables built with the --disable-year2038 option on
GNU/Linux x86 or ARM will of course stop working after 2038, so it's not
an option I recommend.
[0001-Simplify-socket-symlink-attack-checking.patch (text/x-patch, attachment)]
[0002-Update-from-Gnulib-by-running-admin-merge-gnulib.patch (text/x-patch, attachment)]
[0003-By-hand-fixes-for-update-from-Gnulib.patch (text/x-patch, attachment)]
[0004-Port-recent-Gnulib-changes-to-MS-Windows.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 25 Jul 2021 06:33:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, teika <at> gmx.com, 33847 <at> debbugs.gnu.org, ulm <at> gentoo.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 24 Jul 2021 16:31:21 -0700
>
> In looking into this, I noticed that our current approach has another
> problem, because admin/merge-gnulib avoids Gnulib's malloc-posix module
> so that the Emacs build procedure need not worry about Gnulib's malloc
> interposition on MS-Windows. However, Gnulib relies on the POSIX malloc
> spec in its own use of malloc, so malloc-posix should be present in
> Emacs; this is for the benefit of some platforms that are neither GNU
> nor MS-Windows.
>
> What we should do is (A) have the Emacs tarball contain whatever Gnulib
> memory-allocation modules Gnulib needs, (B) arrange for Gnulib's
> memory-allocation modules to be inactive on MS-Windows, and (C) arrange
> for Emacs's private implementation of malloc/realloc/free to be
> GNU-compatible.
Right.
> Proposed patches attached to do all this. Patch 4/4 is the one needing
> most scrutiny, since it involves MS-Windows which I don't use.
Thanks, will review that shortly.
> > Can you tell which Gnulib modules are affected by the new
> > "--disable-year2038" option?
>
> No modules are affected by the --disable-year2038 option on MS-Windows.
>
> The --disable-year2038 option has an effect only on 32-bit GNU/Linux x86
> and ARM (glibc 2.34 and later). On these platforms, the option affects a
> good many Gnulib modules as well as Emacs source code directly. This is
> because the option affects anything that gets or sets a timestamp from
> the OS. 'stat' syscalls, for example.
>
> As I understand it, MS-Windows switched to 64-bit time_t back in 2005
> (even on 32-bit platforms), and nowadays you have to explicitly request
> 32-bit time_t (does anybody do that when building Emacs? I hope not).
This is only mostly correct. It is true that MS-Windows switched to
64-bit time_t as the preferred method some time ago even on 32-bit
versions of Windows. But to build an Emacs that will run on versions
of Windows before the switch, which means all versions before XP, you
_must_ compile with 32-bit time_t, because those older platforms
simply don't have the 64-bit time_t variants of relevant libc
functions in their C runtime DLL, so Emacs using 64-bit time_t will
refuse to start on them. And since we still try to support those
older systems, the 32-bit build of Emacs on Windows does use 32-bit
time_t -- if it is built with mingw.org's MinGW (where time_t is a
32-bit type by default, so no need for any specific requests), because
MinGW64 tossed the support for those older versions long ago, and thus
even its 32-bit versions cannot be used to build an Emacs which will
run on anything before Vista.
> The --disable-year2038 option does not have any effect on MS-Windows,
> because nobody has bothered to add support for that option on that
> platform and I expect and hope that nobody ever will.
So therefore my question seems to be even more important than I
thought, and I'm still asking which Gnulib modules are affected by
this, because I'd need to audit them carefully to see whether the
32-bit MS-Windows build with mingw.org's MinGW could be affected. Can
you show the list of those modules (out of those which Emacs imports),
so I could take a look at them?
> Any Emacs executables built with the --disable-year2038 option on
> GNU/Linux x86 or ARM will of course stop working after 2038, so it's not
> an option I recommend.
That's 17 years in the future, so it will be a real concern in about
15 years, I'd say. let's talk then ;-)
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 25 Jul 2021 07:29:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, teika <at> gmx.com, 33847 <at> debbugs.gnu.org, ulm <at> gentoo.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 24 Jul 2021 16:31:21 -0700
>
> From 4f8392f633cbd3b978c05b972983cfef82be4e7b Mon Sep 17 00:00:00 2001
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 24 Jul 2021 16:11:16 -0700
> Subject: [PATCH 4/4] Port recent Gnulib changes to MS-Windows
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> * nt/gnulib-cfg.mk (OMIT_GNULIB_MODULE_free-posix)
> (OMIT_GNULIB_MODULE_malloc-posix)
> (OMIT_GNULIB_MODULE_realloc-gnu)
> (OMIT_GNULIB_MODULE_realloc-posix):
> New macros, since we don’t want these modules on MS-Windows.
> * src/w32heap.c (heap_alloc, heap_realloc): New functions.
> (malloc_after_dump, realloc_after_dump, realloc_before_dump):
> Use them.
Thanks, this LGTM, but I have one minor request:
> +static void *
> +heap_alloc (size_t size)
> +{
> + void *p = size <= PTRDIFF_MAX ? HeapAlloc (heap, 0, size | !size) : NULL;
Please add a comment here to explain the rationale for the
"size | !size" trick.
> +static void *
> +heap_realloc (void *ptr, size_t size)
> +{
> + void *p = (size <= PTRDIFF_MAX
> + ? HeapReAlloc (heap, 0, ptr, size | !size)
Likewise here.
Btw, HeapAlloc does return a non-NULL pointer if SIZE is zero, so I'm
not sure the protection is needed. But it cannot hurt.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 25 Jul 2021 16:23:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 33847 <at> debbugs.gnu.org (full text, mbox):
On 7/24/21 11:32 PM, Eli Zaretskii wrote:
>> No modules are affected by the --disable-year2038 option on MS-Windows.
It turns out that I was wrong about that. (I don't normally look at the
MS-Windows part of Gnulib and misunderstood some of the code I was
reading.) Please see gnulib/m4/year2038.m4 for details. This file is in
the patches I sent, or you can see it directly here:
https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/year2038.m4
This code knows about MS-Windows, Mingw, _USE_32BIT_TIME_T,
__MINGW_USE_VC2005_COMPAT, and so forth, and attempts to do the right
thing. As near as I can make out it should work for the scenario you
describe, but I don't use MS-Windows so I could well be wrong. If I'm
wrong and this code doesn't do what you want, I suggest contacting
bug-gnulib to alert Bruno Haible, who wrote that part of the code. I'll
cc bug-gnulib so that Bruno sees this email. (Bruno, this discussion is
at <https://bugs.gnu.org/33847#161>.)
Here's some more background. There are two Gnulib modules involved.
The largefile module ensures that a program can open/stat/etc. all
files, by widening types like off_t, dev_t and time_t if necessary. If
it finds that time_t is narrower than what the system can support, it
attempts to widen time_t; if this attempt fails it issues a warning but
continues.
The year2038 module is stricter: it insists that time_t be at least 64
bits and aborts 'configure' otherwise. (Strictly speaking, it should
insist only on at least 33 bits (or 32 bits unsigned); I suppose I
should look into fixing that.)
The Emacs patches that I sent do not use the year2038 module, because I
expected that you wouldn't want to worry about the year 2038. The
year2038 module is used by GNU packages like coreutils where Y2038 is a
problem even now, due to the long lead times and lack of updatability on
systems that use these other GNU packages.
> So therefore my question seems to be even more important than I
> thought, and I'm still asking which Gnulib modules are affected by
> this, because I'd need to audit them carefully to see whether the
> 32-bit MS-Windows build with mingw.org's MinGW could be affected.
There should be no need to audit, because Gnulib still supports
platforms that have only 32-bit time_t.
Gnulib is agnostic about time_t width, and is supposed to work even if
time_t is 40 bits (which it is on a very few mainframes) or any other
width. We regularly test it only on 32- and 64-bit time_t, though.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Sun, 25 Jul 2021 16:36:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 33847 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, teika <at> gmx.com, 33847 <at> debbugs.gnu.org, ulm <at> gentoo.org,
> Gnulib bugs <bug-gnulib <at> gnu.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 25 Jul 2021 09:22:06 -0700
>
> On 7/24/21 11:32 PM, Eli Zaretskii wrote:
>
> >> No modules are affected by the --disable-year2038 option on MS-Windows.
>
> It turns out that I was wrong about that. (I don't normally look at the
> MS-Windows part of Gnulib and misunderstood some of the code I was
> reading.) Please see gnulib/m4/year2038.m4 for details. This file is in
> the patches I sent, or you can see it directly here:
>
> https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/year2038.m4
>
> This code knows about MS-Windows, Mingw, _USE_32BIT_TIME_T,
> __MINGW_USE_VC2005_COMPAT, and so forth, and attempts to do the right
> thing. As near as I can make out it should work for the scenario you
> describe, but I don't use MS-Windows so I could well be wrong. If I'm
> wrong and this code doesn't do what you want, I suggest contacting
> bug-gnulib to alert Bruno Haible, who wrote that part of the code. I'll
> cc bug-gnulib so that Bruno sees this email. (Bruno, this discussion is
> at <https://bugs.gnu.org/33847#161>.)
Thanks, I will take a look, although I now understand it isn't urgent,
since Emacs doesn't (yet) use the year2038 module.
> > So therefore my question seems to be even more important than I
> > thought, and I'm still asking which Gnulib modules are affected by
> > this, because I'd need to audit them carefully to see whether the
> > 32-bit MS-Windows build with mingw.org's MinGW could be affected.
>
> There should be no need to audit, because Gnulib still supports
> platforms that have only 32-bit time_t.
>
> Gnulib is agnostic about time_t width, and is supposed to work even if
> time_t is 40 bits (which it is on a very few mainframes) or any other
> width. We regularly test it only on 32- and 64-bit time_t, though.
Thanks, that's good to know.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 23 Aug 2021 11:24:04 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org.
(Mon, 04 Oct 2021 06:39:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33847; Package
emacs.
(Mon, 04 Oct 2021 06:46:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 33847 <at> debbugs.gnu.org (full text, mbox):
I finally got around to installing into the emacs-28 branch the
emacsclient.c patch that was the first patch in my July 24 email,
archived here:
https://debbugs.gnu.org/33847#161
I reworked that email's remaining patches (which updated from Gnulib),
and today posted the reworked versions into a later bug report, here:
https://debbugs.gnu.org/50985#11
and I plan to follow up in that bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 01 Nov 2021 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 174 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.