Does it make sense to define a constant for openat and such that is guaranteed not to be used for special purposes later on?

* Does it make sense to define a constant for openat and such that is guaranteed not to be used for special purposes later on?
@ 2014-06-28 19:16 Steven Stewart-Gallus
       [not found] ` <fb54be9c497f.53af14a5-BTv7Ps/Sm75C8prJL3GQQw@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: Steven Stewart-Gallus @ 2014-06-28 19:16 UTC (permalink / raw)
  To: linux-api-u79uwXL29TY76Z2rM5mHXA

Hello,

For system calls such as openat I might wish to use the value -1 for
the directory file descriptor parameter to indicate that a path passed
in must be an absolute path. However, it has occurred to me that such
a usage isn't defined by POSIX and isn't safe for the future. In the
future -1 may be taken to be used for some other special purpose. I
would like a solution for that problem.

It'd be nice if we could define a constant (maybe call it AT_FDNODIR)
to maybe -1 that is set aside to mean that no directory is to be used
and that will not ever be ever used for some other purpose in the
future. This way I would be able to use this feature in the future and
not accidentally trigger unexpected functionality that might result in
application misbehaviour or even security holes. This would require
absolutely zero changes in the code and only documentation
changes. Eventually, GLibc would have to define the constant in their
headers for Linux features but I expect most people would define it
themselves for now. The documentation might be something like: "If
dirfd is AT_FDNODIR (defined to be -1) then pathname must be
absolute." Eventually, in the far off future people might want to
deprecate the various *at system calls and upgrade them with new
versions so that new AT_FD* constants can be used. When that happens
AT_FDNODIR would be preserved as a constant requiring that the
pathname must be absolute.

Alternatively, there is no point to adding new AT_FD* constants and
the developers of Linux can promise that in the future any constant
except for the current value of AT_FDCWD will have the present effect
that they have. Note that in the future other interests like POSIX
might want to add new AT_FD* constants so even if the developers of
Linux don't care about adding new AT_FD* constants there still might
be pressure for them to add new AT_FD* constants.

Of course, one might argue that the feature of requiring an absolute
path in a system call is pointless and should not be supported. I
would argue that many system calls have potential security risks and
problems if they do not refer to an absolute path. In particular, this
feature would be useful for the proposed execveat system call (which
has the same problem with close on execute files as fexecve does).

I would be happy with either of the first two approaches and argue
against but still accept the Linux developers arguing the feature is
useless.

Thank you,
Steven Stewart-Gallus

^ permalink raw reply	[flat|nested] 4+ messages in thread