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

Ben Laurie ben at algroup.co.uk
Tue Jan 10 07:43:58 EST 2006

David Hopwood wrote:
> 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.

According to the description, fexecve would execute a named file
relative to a directory identified by an fd, not directly execute the fd.

> -------- 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()
> [...]

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

More information about the cap-talk mailing list