[cap-talk] POSIX adding more file-descriptor-based APIs
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
> 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
> 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
> * 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:
"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