[cap-talk] POSIX adding more file-descriptor-based APIs

[David Hopwood]

This proposed set of additions to POSIX looks interesting in the context
of file-descriptor-based approaches to capabilities on Unix (e.g. Plash).

The assumption still seems to be that the fds will identify directories in
a global namespace, but it is not a very big step from this to using local
namespaces.

Also, if fexecve is what I'm guessing it is from the name (exec'ing a
file identified by an fd), ISTR that Plash currently uses some horribly
complicated workaround to implement that.


-------- Original Message --------
Subject: Proposed submissions for the revision from The Open Group
Resent-Date: 9 Jan 2006 18:48:27 -0000
Resent-From: austin-group-l at opengroup.org
Resent-To: austin-group-l at opengroup.org
Date: Mon, 9 Jan 2006 18:47:58 GMT
From: Andrew Josey <ajosey at rdg.opengroup.org>
To: austin-group-l at opengroup.org

All
This is a note to record the proposed submissions for
the revision project from The Open Group.

The Open Group Base Working Group is considering submitting
a number of API sets for the revision.  These are currently undergoing
development as Technical Standards and are expected to complete in time
to meet the July 31 Austin Group Revision milestone.

The purpose of these Technical Standards is to define sets of New API
Extensions to further increase application capture and hence portability
for systems built upon version 3 of the Single UNIX Specification .


API Set 1:

The scope of this set of extensions has been to consider interfaces
drawn from existing open source implementations such as the GNU C library.

[snip; not relevant to cap-talk]

API Set 2:

The motivation for the introduction of this set of interfaces is as
follows:

    * Interfaces taking a path name are limited by the maximum length of
    a path name(_SC_PATH_MAX). The absolute path of files can far exceed
    this length. The current solution would be to change the working
    directory and use relative path names. This is not thread-safe.

    * A second motivation is that files accessed outside the current
    working directory are subject to attacks caused by the race condition
    created by change any of the elements of the path names used.

    * A third motivation is to allow implementing code which uses a
    virtual current working directory for each individual thread. In
    the current model there is only one current working directory for
    all threads.

The new interfaces solve these issues by duplicating existing interfaces
using path names with one change, that is an additional parameter. This
additional parameter must be a file descriptor for a directory. The
operations will then work relative to the specified directory instead
of the current working directory whenever the later would be accessed.

The set of interfaces includes:

faccessat()
fchmodat()
fchownat()
fdopendir()
fexecve()
fstatat()
futimesat()
linkat()
mkdirat()
mkfifoat()
mknodat()
openat()
readlinkat()
renameat()
symlinkat()
unlinkat()

[...]

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>