From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 12632@debbugs.gnu.org
Subject: bug#12632: file permissions checking mishandled when setuid
Date: Tue, 23 Oct 2012 18:44:57 +0200 [thread overview]
Message-ID: <83vce1b0ja.fsf@gnu.org> (raw)
In-Reply-To: <50862604.30208@cs.ucla.edu>
> Date: Mon, 22 Oct 2012 22:07:16 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rgm@gnu.org, 12632@debbugs.gnu.org
>
> Which of the following calls can fail on Windows in the current
> Emacs trunk, and why?
>
> sys_access ("/", D_OK) sys_access ("/.", D_OK)
> sys_access ("\\", D_OK) sys_access ("\\.", D_OK)
> sys_access ("//", D_OK) sys_access ("//.", D_OK)
> sys_access ("/\\", D_OK) sys_access ("/\\.", D_OK)
> sys_access ("\\/", D_OK) sys_access ("\\/.", D_OK)
> sys_access ("\\\\", D_OK) sys_access ("\\\\.", D_OK)
> sys_access ("///", D_OK) sys_access ("///.", D_OK)
Sorry, I cannot afford doing this research. Some of these file names
have no meaning at all, so they are prone to undefined behavior.
Others, like "//.", are downright dangerous, because "\\.\" begins a
device name on Windows. With these arcana notoriously
under-documented by MS, it is anybody's guess what such names can do
in what APIs.
I'm trying to avoid potential problems before they have a chance to
screw some user. I don't see a reason to seek a 110% provable test
case, when the issue at hand is a single use of a macro that is used
all over the place in Emacs.
There isn't a single comparison with a literal '/' in fileio.c, with
the sole exception of supporting the "/:" magic. More than 50
instances of IS_DIRECTORY_SEP, just in that one file (and several
dozens more elsewhere in Emacs), are the evidence that
IS_DIRECTORY_SEP _is_ the norm, whereas a literal slash is an
exception. Contrary to your original claim, using '/' will confuse
the reader into thinking that this particular function does something
special, like the code which looks for the "/:" magic, while using
IS_DIRECTORY_SEP will look like any other code we have, and will also
DTRT instead of relying on "maybe it will work".
> > The call to faccessat could fail, just because of the "\/." at the
> > end of the file name.
>
> Sorry, I don't follow this example. The code doesn't append
> backslash-slash-dot; it appends slash-dot. Are you saying that
> in the current trunk, sys_access ("\\", D_OK) can succeed
> but sys_access ("\\/.", D_OK) can fail when presented with
> the same file system?
No, I'm saying that if the function is called with "d:\foo\", it will
call faccessat with "d:\foo\/." as the argument, which has "\/." at
the end of the file name. Testing with IS_DIRECTORY_SEP will avoid
this and call faccessat with "d:\foo/.". The latter is a valid file
name, while the former is not.
next prev parent reply other threads:[~2012-10-23 16:44 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-13 1:58 bug#12632: file permissions checking mishandled when setuid Paul Eggert
2012-10-13 7:23 ` Eli Zaretskii
2012-10-13 8:36 ` Eli Zaretskii
2012-10-14 6:16 ` Paul Eggert
2012-10-14 6:56 ` Eli Zaretskii
2012-10-14 18:14 ` Paul Eggert
2012-10-14 18:39 ` Eli Zaretskii
2012-10-14 19:42 ` Paul Eggert
2012-10-14 20:10 ` Eli Zaretskii
2012-10-14 20:17 ` Eli Zaretskii
2012-10-14 20:40 ` Paul Eggert
2012-10-14 20:53 ` Eli Zaretskii
2012-10-15 6:17 ` Paul Eggert
2012-10-15 17:31 ` Eli Zaretskii
2012-10-15 21:38 ` Paul Eggert
2012-10-16 3:46 ` Eli Zaretskii
2012-10-16 6:00 ` Paul Eggert
2012-10-16 16:36 ` Eli Zaretskii
2012-10-19 17:01 ` Paul Eggert
2012-10-19 18:41 ` Eli Zaretskii
2012-10-19 18:54 ` Paul Eggert
2012-10-19 19:05 ` Glenn Morris
2012-10-19 19:36 ` Paul Eggert
2012-10-20 2:25 ` Richard Stallman
2012-10-20 4:36 ` Paul Eggert
2012-10-21 1:44 ` Glenn Morris
2012-10-21 2:52 ` Paul Eggert
2012-10-21 4:24 ` Glenn Morris
2012-10-22 6:03 ` Paul Eggert
2012-10-22 17:19 ` Eli Zaretskii
2012-10-22 20:33 ` Paul Eggert
2012-10-22 21:04 ` Eli Zaretskii
2012-10-22 21:30 ` Paul Eggert
2012-10-23 0:40 ` Stefan Monnier
2012-10-23 1:46 ` Paul Eggert
2012-10-23 3:49 ` Eli Zaretskii
2012-10-23 3:47 ` Eli Zaretskii
2012-10-23 5:07 ` Paul Eggert
2012-10-23 16:44 ` Eli Zaretskii [this message]
2012-10-23 19:27 ` Paul Eggert
2012-10-23 19:50 ` Eli Zaretskii
2012-10-23 20:01 ` Paul Eggert
2012-10-23 23:15 ` Andy Moreton
2012-10-24 3:51 ` Eli Zaretskii
2012-10-19 19:10 ` Eli Zaretskii
2012-11-13 2:19 ` bug#12632: updated version of the patch Paul Eggert
2012-11-14 5:10 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83vce1b0ja.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=12632@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.