Extended API Set Part 2 Preliminary Dispositions Page 1 of 1 Submitted by Andrew Josey, The Open Group. March 15, 2006 These are the dispositions of the aardvark after the Change Request review meeting. These will next be subject to balloting by the Base Working Group. Aardvark Summary Table ______________________ ERN 1 Reject ERN 2 Reject ERN 3 Accept ERN 4 Accept as marked ERN 5 Accept as marked ERN 6 Duplicate of 7 ERN 7 Accept ERN 8 Accept ERN 9 Accept as marked ERN 10 Accept ERN 11 Accept ERN 12 Accept ERN 13 Accept ERN 14 Accept ERN 15 Accept ERN 16 Accept ERN 17 Accept ERN 18 Accept ERN 19 Accept as marked ERN 20 Accept ERN 21 Accept ERN 22 Accept as marked ERN 23 Reject ERN 24 Accept ERN 25 Accept ERN 26 Accept _____________________________________________________________________________ OBJECTION Enhancement Request Number 1 bruno@clisp.org Bug in ExtAPI_2.1 3 (rdvk# 7) {GNU-haible-001} Fri, 3 Mar 2006 12:39:52 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The working group rejected this proposal. It is out of scope for The Open Group company review, since the interface names are drawn from existing practice, and there are no known conflicts with the names. _____________________________________________________________________________ Page: 0 Line: 0 Section: 3 Problem: The naming of the functions is unorthogonal: 1) Some of the functions have a prefix "f" which has no meaning. 2) While POSIX usually uses a prefix to indicate a group of functions (such as "inet_", "dbm_", "pthread_") and usually uses a suffix to indicate the data type it operates on ("c" for char, "wc" for wide character, "id" for id, "f" for float or FILE, "l" for long, "ll" for long long), this proposal uses a _suffix_ for a new group of functions. 3) While the macros have a prefix "AT_", the functions have a _suffix_ "at". Action: Use the names atopen, atrename, atstat, atmkdir, atmkfifo, atmknod, atutimes, ataccess, atchmod, atchown, atexecve, atlink, atreadlink, atsymlink, atunlink. Alternatively, use the names posix_open, posix_rename, posix_stat, posix_mkdir, posix_mkfifo, posix_mknod, posix_utimes, posix_access, posix_chmod, posix_chown, posix_execve, posix_link, posix_readlink, posix_symlink, posix_unlink. _____________________________________________________________________________ OBJECTION Enhancement Request Number 2 hpa@zytor.com Bug in ExtAPI_2.1 All (rdvk# 25) {hpa-1} Sat, 4 Mar 2006 05:43:02 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The working group rejected this proposal. It is out of scope for The Open Group company review, since the interface names are drawn from existing practice, and there are no known conflicts with the names. _____________________________________________________________________________ Page: 0 Line: 0 Section: All Problem: Historically, POSIX has had functions with f- prefixes operating on file descriptors, and without prefixes operating on pathnames. This proposal introduces a new set of interfaces, operating on (directory filedescriptor, pathname) pairs. This is a highly useful extension, however, the proposal does not introduce a consistent naming convention for these interfaces. Most of the new interfaces are indicated with an -at() suffix, however, some have *both* a leading f- prefix and the tailing -at suffix. This is an extremely unfortunate, since it seems to indicate to the programmer that there is a distinction which does not exist. Furthermore, it is guaranteed to result in "what was that function named again" syndrome. One of the historical strengths of the Unix/POSIX interface is a set of easily understood, consistently named interfaces which is easy for a programmer to understand, remember, and most importantly, use correctly. I therefore consider it a major defect on the level of an Objection to introduce an inconsistent naming convention to the detriment of the programmer. Action: Rename the interfaces faccessat(), fchmodat(), fchownat(), fstatat(), and futimesat() to accessat(), chmodat(), statat(), and utimesat(). _____________________________________________________________________________ COMMENT Enhancement Request Number 3 don.cragun@Sun.COM Bug in ExtAPI_2 (rdvk# 14) {DWC-API2-1} Fri, 3 Mar 2006 15:22:08 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The editors will fix _____________________________________________________________________________ Page: 3 Line: 19-27 Section: 2.1 Problem: The description of the UX margin code here only applies to changes in XBD. This draft also makes changes to XSH and uses the UX margin code and shading in XSH, but does not specify addition of this new code in that volume. Action: Unless this change goes into a file that is shared in XBD, XCU, XSH, and XRAT, add corresponding changes for XSH section 1.8.1. If it is shared between all of the volumes, add a note saying so in the Notes To Reviewers on P3, L21-22. _____________________________________________________________________________ COMMENT Enhancement Request Number 4 don.cragun@Sun.COM Bug in ExtAPI_2 (rdvk# 15) {DWC-API2-2} Fri, 3 Mar 2006 15:22:08 -0800 (PST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Yes this a separate option for now, as all the API sets undergoing company review are.We plan to produce a set of editing recommendations for the submission of materials to the Austin Group in July. ACTION: An action arising from this is to produce a paper on proposed options for the submission of materials to the Austin Group specificaton. That will need to go for a company review within The Open Group _____________________________________________________________________________ Page: 3 Line: 21,25 Section: 2.1 Problem: Extended API Set 1 also uses the UX margin code. There is no reason to believe at this point that both sets won't be accepted, and there is no reason yet to believe that these API sets should not be kept as distinct options in the next revision of the standard. To avoid possible merging problems in a future SUSv4 draft, a different margin code should be used in this API set. Action: Globally change the UX margin code in this draft to something like UX2. Globally change "Extended Interfaces option" in this draft to something like "Extended Interfaces Set 2 option". _____________________________________________________________________________ OBJECTION Enhancement Request Number 5 eggert@ucla.edu Bug in ExtAPI_2.1 AT_FDCWD (rdvk# 3) {20060301a} Wed, 1 Mar 2006 22:46:05 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change the wording to: a special value used in place of a file descriptor _____________________________________________________________________________ Page: 3 Line: 36 Section: AT_FDCWD Problem: The text says that AT_FDCWD is a "file descriptor value". However, file desciptors are by definition nonnegative, whereas in practice AT_FDCWD is negative to indicate that it is not a file descriptor value. Action: In page 3 line 36 change "a special file descriptor value" to "a negative 'int' value intended to be used in place of a file descriptor". _____________________________________________________________________________ COMMENT Enhancement Request Number 6 bruno@clisp.org Bug in ExtAPI_2.1 openat (rdvk# 9) {GNU-haible-003} Fri, 3 Mar 2006 13:08:02 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_7_ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3 Line: 39 Section: openat Problem: When using openat() to open a file for writing, it is impossible to ensure that it is not a symlink pointing to a location where it is not appropriate to write to. This is a security issue. The application programmer can call fstatat() with AT_SYMLINK_NOFOLLOW flag before calling openat(), but this still leaves a time window, where an attacker could replace a regular file with a symlink. Action: Change the description of openat() to support the AT_SYMLINK_NOFOLLOW flag. Specify that openat() fails with errno = ELOOP when AT_SYMLINK_NOFOLLOW is specified and the file exists and is a symbolic link. Change the description of AT_SYMLINK_NOFOLLOW to mention that openat() supports it. Alternatively, specify that defines a macro O_NOFOLLOW. Change the description of openat() to support the O_NOFOLLOW flag. Specify that openat() fails with errno = ELOOP when O_NOFOLLOW is specified and the file exists and is a symbolic link. _____________________________________________________________________________ OBJECTION Enhancement Request Number 7 eggert@ucla.edu Bug in ExtAPI_2.1 fcntl.h (rdvk# 6) {20060302a} Thu, 2 Mar 2006 21:46:44 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3 Line: 41 Section: fcntl.h Problem: The proposed interface provides AT_SYMLINK_NOFOLLOW, which prevents fstatat, fchmodat, and fchownat from following symbolic links. But there is no way for open or openat to refuse to follow symbolic links. This is a severe limitation on the proposed interface, but common practice does not have this limitation. Common practice is to provide a constant O_NOFOLLOW that can be passed as a flag to 'open'. Another possibility might be to allow AT_SYMLINK_NOFOLLOW to be passed to 'openat', but the proposed action merely standardizes existing practice. Action: Page 3 line 41 add the following text: The following is a value for _flag_ used by open() and openat(): O_NOFOLLOW Do not follow symbolic links. Page 5 line 85 add a new section (between 3.1 and 3.2) as follows: 3.x Changes to File-Related Manual Pages: Make the following changes to the open() page. Add the following description between O_NOCTTY and O_NONBLOCK: O_NOFOLLOW If _path_ names a symbolic link, fail and set errno to ELOOP. Under ERRORS, change from: [ELOOP] A loop exists in symbolic links encountered during resolution of the _path_ argument. to: [ELOOP] A loop exists in symbolic links encountered during resolution of the _path_ argument, or O_NOFOLLOW was specified and the _path_ argument names a symbolic link. In the rationale, insert the following text after the paragraphs talking about symbolic links, O_CREAT, and O_EXCL. In addition, the open() function does not follow symbolic links if the O_NOFOLLOW flag is set. This avoids race conditions whereby a user might compromise the system by substituting a symbolic link to a sensitive file (e.g., a device) while a privileged application is running, where opening the file even for read access might have undesirable side effects. _____________________________________________________________________________ OBJECTION Enhancement Request Number 8 eggert@ucla.edu Bug in ExtAPI_2.1 fcntl.h (rdvk# 5) {20060302b} Fri, 3 Mar 2006 00:35:33 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 3 Line: 41 Section: fcntl.h Problem: There's a general problem with all the proposed new unistd.h functions. With the proposed API, one cannot open a directory D to obtain a file descriptor that can be used as the first argument to openat, fstatat, mkdirat, etc., unless one has read access to D. But the first argument of openat, fstatat, etc., is used for searching, not for reading, so this is a functional mismatch. A process should be able to open a directory for openat/etc. purposes depending on whether the process has search access to the directory, not read access. There's a related problem with fexecve. The rationale for fexecve says the goal is to enable executing a file that has been opened via openat. However, there's an important limitation to the current interface: the method can be used only on files that the user can read or write, and cannot be used on execute-only files. This renders the proposed interface less useful than it might otherwise be. And in some sense the interface is incorrect: it requires read (or write) access to the file, whereas it should be requiring execute access. There is an existing-practice solution to this problem, in the GNU system: a macro O_EXEC that that asks for execute access to a file. Action: Page 3 line 41 add the following text: The following is a value for _flag_ used by open() and openat(): O_EXEC Open the file for executing/search. Page 5 line 85 add a new section (between 3.1 and 3.2) as follows: 3.x Changes to File-Related Manual Pages: Make the following changes to the open() page. Change from: Applications shall specify exactly one of the first three values (file access modes) below in the value of oflag: O_RDONLY Open for reading only. O_WRONLY Open for writing only. O_RDWR Open for reading and writing. The result is undefined if this flag is applied to a FIFO. to: Applications shall either specify exactly one of the first three values (which are file access modes) below in the value of oflag, or shall specify O_EXEC and at most one of the first three values. O_RDONLY Open for reading without write access. O_WRONLY Open for writing without read access. O_RDWR Open for reading and writing. The result is undefined if this flag is applied to a FIFO. Add the following description between O_EXCL and O_NOCTTY: O_EXEC Open for executing/search. If this option is specified with O_RDONLY, O_WRONLY, or O_RDWR, then executing/search permission is required in addition to the other requested permissions; otherwise, only executing/search permission is required. Under O_TRUNC, change from: The result of using O_TRUNC with O_RDONLY is undefined. to: The result of using O_TRUNC without either O_RDWR or O_WRONLY is undefined. In the rationale, insert the following text after the paragraphs talking "Opening a File for Writing". The following example opens a file for searching. #include #include #include ... int pfd; ... if ((pfd = open("/tmp", O_EXEC)) == -1) { perror("Cannot search /tmp\n"); exit(1); } In the rationale, after the "O_RDONLY | O_WRONLY == O_RDWR", insert the following text: Historical implementations did not have the O_EXEC flag, but this has been added to allow implementations to obtain access to a search-only directory for later use with fchdir, openat, and the like. _____________________________________________________________________________ OBJECTION Enhancement Request Number 9 eggert@ucla.edu Bug in ExtAPI_2.1 fcntl.h (rdvk# 10) {20060303c} Fri, 3 Mar 2006 23:10:33 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Note that open() can open any file. A portable program can use open() with the trailing slash to get the same effect. The standard developers felt this would be a useful extension. Page 3 line 41 add the following text: The following is a value for _flag_ used by open() and openat(): O_DIRECTORY Fail if not a directory. Page 5 line 85 add a new section (between 3.1 and 3.2) as follows: 3.x Changes to File-Related Manual Pages: Make the following changes to the open() page. Add the following description between O_CREAT and O_DSYNC O_DIRECTORY If _path_ does not name a directory, fail and set errno to ENOTDIR. Under ERRORS, change from: [ENOTDIR] A component of the path prefix is not a directory. to: [ENOTDIR] A component of the path prefix is not a directory, or O_DIRECTORY was specified and the _path_ argument does not name a directory. In the rationale, insert the following text after the paragraphs talking about symbolic links, O_CREAT, and O_EXCL. In addition, the open() function refuses to open non-directories if the O_DIRECTORY flag is set. This avoids race conditions whereby a user might compromise the system by substituting a hard link to a sensitive file (e.g., a device or a fifo) while a privileged application is running, where opening the file even for read access might have undesirable side effects. Make the following change to the opendir() page. At the end of DESCRIPTION, add: If the type DIR is implemented using a file descriptor, the descriptor shall be obtained as if the O_DIRECTORY flag was passed to open(). _____________________________________________________________________________ Page: 3 Line: 41 Section: fcntl.h Problem: The rationale for openat/fdopendir says that they are designed to avoid race conditions, but the proposed interface still allows a race condition, even if the O_NOFOLLOW suggested by my 20060302a comment is accepted. Common practice suggests a solution. Here's the race condition. Suppose a privileged process is executing the equivalent of "rm -fr /tmp/dir", where /tmp/dir is owned by an attacker. The privileged process will do something like the following (error-checking omitted): int FD = open("/tmp/dir", O_RDONLY); DIR *D = fdopendir(FD); struct dirent *SD = readdir(D); struct stat SB; fstatat(FD, SD->d_name, &SB); if (S_ISDIR(SB.st_mode)) { /* The attacker strikes here. */ int FD1 = openat(FD, "subdir", O_RDONLY | O_NOFOLLOW); struct stat SB1; fstat(FD1, &SB1); if (SB.st_dev != SB1.st_dev || SB.st_ino != SB1.st_ino) error("Some funny business is going on here!"); } Now, suppose at the point marked "The attacker strikes here", SD->d_name is "subdir", and the attacker executes the following commands: rm -fr /tmp/dir/subdir ln /dev/rmt0 /tmp/dir/subdir Then the openat will open a tape drive, possibly with side effects like rewinding the tape. The code will detect that some funny business is going on (because the device and inode numbers will disagree), but by then it's too late; the tape is rewound. A similar problem can occur by hard-linking to other kinds of files, e.g., fifos and pseudo-terminals. GNU/Linux addresses this problem with an O_DIRECTORY flag, which causes the open to fail if the file is not a directory. Other solutions are possible but the proposed action adopts this existing practice. Action: Page 3 line 41 add the following text: The following is a value for _flag_ used by open() and openat(): O_DIRECTORY Fail if not a directory. Page 5 line 85 add a new section (between 3.1 and 3.2) as follows: 3.x Changes to File-Related Manual Pages: Make the following changes to the open() page. Add the following description between O_CREAT and O_DSYNC O_DIRECTORY If _path_ does not name a directory, fail and set errno to ENOTDIR. Under ERRORS, change from: [ENOTDIR] A component of the path prefix is not a directory. to: [ENOTDIR] A component of the path prefix is not a directory, or O_DIRECTORY was specified and the _path_ argument does not name a directory. In the rationale, insert the following text after the paragraphs talking about symbolic links, O_CREAT, and O_EXCL. In addition, the open() function refuses to open non-directories if the O_DIRECTORY flag is set. This avoids race conditions whereby a user might compromise the system by substituting a hard link to a sensitive file (e.g., a device or a fifo) while a privileged application is running, where opening the file even for read access might have undesirable side effects. Make the following change to the opendir() page. At the end of DESCRIPTION, add: If the type DIR is implemented using a file descriptor, the descriptor shall be obtained using the equivalent of the O_DIRECTORY flag of open(). as if the O_DIRECTORY flag was _____________________________________________________________________________ EDITORIAL Enhancement Request Number 10 don.cragun@Sun.COM Bug in ExtAPI_2 (rdvk# 16) {DWC-API2-3} Fri, 3 Mar 2006 15:22:08 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 4 Line: 52 Section: 2.2 Problem: A function prototype contains extraneous whitespace. Action: Change: DIR *fdopendir (int); on P3, L34 to: DIR *fdopendir(int); Change: int renameat (int, const char *, int, const char *); on P4, L52 to: int renameat(int, const char *, int, const char *); _____________________________________________________________________________ EDITORIAL Enhancement Request Number 11 don.cragun@Sun.COM Bug in ExtAPI_2 (rdvk# 17) {DWC-API2-4} Fri, 3 Mar 2006 15:22:08 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 4 Line: 60-63 Section: 2.2 Problem: A few function prototypes contain extraneous whitespace. Action: Change: int fstatat (int, const char *, struct stat *, int); int mkdirat (int, const char *, mode_t); int mkfifoat (int, const char *, mode_t); int mknodat (int, const char *, modt_t, dev_t ); on P4, L60-63 to: int fstatat(int, const char *, struct stat *, int); int mkdirat(int, const char *, mode_t); int mkfifoat(int, const char *, mode_t); int mknodat(int, const char *, modt_t, dev_t); Note that two spaces were removed from the last line. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 12 don.cragun@Sun.COM Bug in ExtAPI_2 (rdvk# 18) {DWC-API2-5} Fri, 3 Mar 2006 15:22:08 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 4 Line: 71-78 Section: 2.2 Problem: Several function prototypes contain extraneous whitespace. Action: Change: int faccessat (int, const char *, int); int fchmodat (int, const char *, mode_t, int); int fchownat (int, const char *, uid_t gid_t, int); int fexecve (int, char *const [], char *const []); int linkat (int, const char *, int, const char *); int readlinkat (int, const char *, char *, size_t); int symlinkat (const char *, int, const char *); int unlinkat (int, const char *, int); on P4, L71-78 to: int faccessat(int, const char *, int); int fchmodat(int, const char *, mode_t, int); int fchownat(int, const char *, uid_t gid_t, int); int fexecve(int, char *const [], char *const []); int linkat(int, const char *, int, const char *); int readlinkat(int, const char *, char *, size_t); int symlinkat(const char *, int, const char *); int unlinkat(int, const char *, int); _____________________________________________________________________________ OBJECTION Enhancement Request Number 13 isaac.wong@hp.com Bug in ExtAPI_2.1 3.1 (rdvk# 1) {HP-MSG_NOSIGNAL} Thu, 9 Feb 2006 22:35:42 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 5 Line: 81-85 Section: 3.1 Problem: There are two problems with the description: 1. Generation of the SIGPIPE signal is tied to the EPIPE error and the EPIPE error is only defined in send(), sendto() or sendmsg(). The EPIPE error is not a defined error in recv(), recvfrom() or recvmsg(). 2. In send(), sendto() and sendmsg() man pages in Single Unix Specification, version 3, EPIPE error is defined as: "[EPIPE] The socket is shut down for writing, or the socket is connection-mode and is no longer connected. In the latter case, and if the socket is of type SOCK_STREAM, the SIGPIPE signal is generated to the calling thread." Breaking the connection by the other end of a stream oriented socket is only one of the few reasons the socket is no longer connected. Action: Delete "recv( ), recvfrom( ), recvmsg()". Change: "MSG_NOSIGNAL Requests not to send the SIGPIPE signal on errors for stream oriented sockets when the other end breaks the connection. The EPIPE error shall still be returned." to: "MSG_NOSIGNAL Requests not to send the SIGPIPE signal if an attempt to send is made on a stream oriented socket that is no longer connected. The EPIPE error shall still be returned." Also at page 4 line 55-56 section 2.2 MSG_NOSIGNAL objection Change: "MSG_NOSIGNAL No SIGPIPE generated on error for stream oriented sockets when the other end breaks the connection." To: "MSG_NOSIGNAL No SIGPIPE generated when an attempt to send is made on a stream oriented socket that is no longer connected." _____________________________________________________________________________ COMMENT Enhancement Request Number 14 don.cragun@Sun.COM Bug in ExtAPI_2 (rdvk# 19) {DWC-API2-6} Fri, 3 Mar 2006 15:22:08 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 7,... Line: 134-136,... Section: faccessat(),... Problem: It seems that the SEE ALSO lists for many of the interfaces added in this draft unnecessarily point to a long list of other *at() functions. For example, the existing access description in the standard just references chmod() and stat() in XSH and in XBD. But, the faccessat() SEE ALSO list on P7, L134-136 specifies access(), fchmodat(), fchownat(), fstatat(), futimesat(), lchown(), linkat(), mkdirat(), mkfifoat(), mknodat(), openat(), readlinkat(), renameat(), symlinkat(), unlinkat(), and and in the Base Definitions volume of IEEE Std 1003.1- 2001. Action: Change the SEE also list on P7, L134-136 to be: access(), chmod(), stat(), the Base Definitions volume of IEEE Std 1003.1-2001, , Change all of the other SEE ALSO sections in this draft to specify a pointer to the underlying function, a pointer to the XBD description of (if it is not already listed), the contents of the SEE ALSO list from the underlying function (appropriately sorted). _____________________________________________________________________________ OBJECTION Enhancement Request Number 15 don.cragun@Sun.COM Bug in ExtAPI_2 (rdvk# 20) {DWC-API2-7} Fri, 3 Mar 2006 15:22:08 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 8 Line: 167 Section: fchmodat() Problem: The current lchown() function in the standard uses EOPNOTSUPP rather than ENOTSUP when specifying that a field in the stat struct can't be updated for a symlink. New functions added at this point should follow the same convention. Action: Change "ENOTSUP" on P8, L167 to "EOPNOTSUPP". _____________________________________________________________________________ OBJECTION Enhancement Request Number 16 don.cragun@Sun.COM Bug in ExtAPI_2 (rdvk# 21) {DWC-API2-8} Fri, 3 Mar 2006 15:22:08 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 8 Line: 167-168 Section: fchmodat() Problem: The description on P8, L151-152 of the condition leading to the ENOTSUP error says that it only happens if path names a symlink. The description of the error condition on L167-168 implies that this error should be returned if the system doesn't support changing the mode of a symlink even if path doesn't name a symlink. Action: Change "argument and" on P8, L167 to "argument, path names a symbolic link, and". _____________________________________________________________________________ OBJECTION Enhancement Request Number 17 don.cragun@Sun.COM Bug in ExtAPI_2 (rdvk# 23) {DWC-API2-10} Fri, 3 Mar 2006 15:22:08 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 10 Line: 220 Section: fchownat() Problem: See also my objection DWC-API2-\nf. XBD6's description of (P360, L12728-12733) says that the only stat structure fields that have to contain meaningful values are st_mode and st_size and that the only portably meaningful bits in st_mode are the ones that specify file type. Therefore, there is no requirement that systems maintain the st_uid nor st_gid fields for symlinks. Action: Add EOPNOTSUPP to the list of may fail errors for fchownat() on P10 after L220 with the description: The path argument names a symbolic link and the implementation does not support setting the owner or group of a symbolic link. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 18 don.cragun@Sun.COM Bug in ExtAPI_2 (rdvk# 22) {DWC-API2-9} Fri, 3 Mar 2006 15:22:08 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 12 Line: 249 Section: fdopendir() Problem: File descriptors don't have positions; directory streams have a position, file descriptors have file offsets. Action: Change "The position of the file descriptor" on P12, L249 to "The file offset associated with the file descriptor". _____________________________________________________________________________ COMMENT Enhancement Request Number 19 bruno@clisp.org Bug in ExtAPI_2.1 fdopendir (rdvk# 8) {GNU-haible-002} Fri, 3 Mar 2006 12:50:35 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to the end of the DESCRIPTION It is unspecified whether the FD_CLOEXEC flag will be set on the file descriptor by a successful call to fdopendir(). _____________________________________________________________________________ Page: 12 Line: 251 Section: fdopendir Problem: The description of fdopendir() does not specify what happens with the file descriptor "under the control of the system" in case of exec(). If the FD_CLOEXEC flag associated with the file descriptor was clear before the fdopendir() call, and closedir() is not called before exec(), is the file descriptor then still valid after exec()? If yes, then what is its semantics? Action: Please clarify. _____________________________________________________________________________ OBJECTION Enhancement Request Number 20 eggert@ucla.edu Bug in ExtAPI_2.1 fdopendir (rdvk# 11) {20060303d} Fri, 3 Mar 2006 23:21:30 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 12 Line: 254 Section: fdopendir Problem: Page 12 line 251-252 says "Upon successful return from fdopendir(), the file descriptor is under the control of the system and should not be used otherwise." This appears to outlaw code that one might naturally write, and that works in all implementations of fdopendir that I know of. For example: int FD = open("/tmp/dir", O_RDONLY); DIR *D = fdopendir(FD); struct dirent *SD = readdir(D); struct stat SB; fstatat(FD, SD->d_name, &SB); The last line uses FD, even though FD "should not be used otherwise". But this use won't break anything in practice. Action: Page 12 line 254-255. Change from: Upon successful return from fdopendir(), the file descriptor is under the control of the system and should not be used otherwise. to: Upon successful return from fdopendir(), the file descriptor is under the control of the system, and if any attempt is made to close the file descriptor, or to modify the state of the associated description other than by means of closedir(), readdir(), readdir_r(), or rewinddir(), the behavior is implementation-defined. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 21 don.cragun@Sun.COM Bug in ExtAPI_2 (rdvk# 24) {DWC-API2-11} Fri, 3 Mar 2006 15:22:08 -0800 (PST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 12 Line: 258-259 Section: fdopendir() Problem: The error codes in the ERRORS section should be sorted. Action: Move P12, L258 to follow P12, L259. _____________________________________________________________________________ OBJECTION Enhancement Request Number 22 eggert@ucla.edu Bug in ExtAPI_2.1 fexecve (rdvk# 26) {20060303e} Sat, 4 Mar 2006 06:43:05 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: At the end of DESCRIPTION. The file offset of fd is ignored _____________________________________________________________________________ Page: 13 Line: 284 Section: fexecve Problem: Page 13 line 284 does not specify what fexecve does if the file description identified by _fd_ has a nonzero file offset. Action: The spec should say, when the file offset is nonzero, whether the behavior is undefined, or implementation-defined, or the file offset is ignored. _____________________________________________________________________________ OBJECTION Enhancement Request Number 23 eggert@ucla.edu Bug in ExtAPI_2.1 futimesat (rdvk# 12) {20060303a} Fri, 3 Mar 2006 21:07:58 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Reject, futimesat() parallels futimes(). And there another proposal for a new function. _____________________________________________________________________________ Page: 17 Line: 374 Section: futimesat Problem: futimesat uses a 'struct timeval' to specify the time stamp on the files. But this has only microsecond resolution. It should use 'struct timespec'. I understand that a high-resolution time stamp proposal is under way; it should be folded into futimesat, so that we don't specify a function whose utility will soon be subsumed by another function. Action: In page 17 line 374, change "struct timeval" to "struct timespec" In page 17 line 377, change "The futimesat() function shall be equivalent to the utimes() function" to "The futimesat() function shall be equivalent to the utimes() function with an increased time stamp resolution". _____________________________________________________________________________ OBJECTION Enhancement Request Number 24 drepper@redhat.com Bug in ExtAPI_2.1 linkat() (rdvk# 2) {ud-linkat-flags} Mon, 27 Feb 2006 06:07:31 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 18 Line: 416 Section: linkat() Problem: The Linux implementation of linkat(), upon which the proposal is based, now takes a fifth parameter. This parameter is a flag value. If the AT_SYMLINK_FOLLOW bit is set the linkat() behavior corresponds to the behavior of link() in POSIX in that symbolic links are followed if path1 specifies a symbolic link. Otherwise a hardlink to the symlink is created. Action: On page 3 after line 41 add: The following is a value for flag used by /linkat()/: AT_SYMLINK_FOLLOW Follow symbolic link. On page 4, line 75: Add ", int flag" to linkat() prototype One page 18, line 416: Add ", int flag" to prototype On page 18, add after line 422: Values for /flag/ are constructed by a bitwise-inclusive OR of flags from the following list, defined in : AT_SYMLINK_FOLLOW If /path1/ names a symbolic link, a new link for the target of the symbolic link is created On page 18, add after line 425: Unless /flag/ contains the AT_SYMLINK_FOLLOW flag, if /path1/ names a symbolic link, a new link is created for the symbolic link /path1/ and not its target. On page 18, add after line 434: [EINVAL] The value of the /flag/ argument is not valid. On page 18, add after line 447: The AT_SYMLINK_FOLLOW flag allows implementing both common behaviors of the link function. The POSIX specification requires that if /path1/ is a symbolic link, a new link for the target of the symbolic link is created. Many systems by default or as an alternative provide a mechanism to avoid the implicit symlink lookup and create a new link for the symbolic link itself. _____________________________________________________________________________ OBJECTION Enhancement Request Number 25 eggert@ucla.edu Bug in ExtAPI_2.1 openat (rdvk# 13) {20060303b} Fri, 3 Mar 2006 21:58:32 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 24 Line: 606 Section: openat Problem: There's a general issue with the proposed new unistd.h functions, with respect to searching the directory identified by the file descriptor that is passed to openat, fstatat, etc. Searching requires an access check against the directory's permissions, but is this access check performed when the file descriptor is created, or is it done on each operation? The Unix tradition is that when you invoke fd=open("FOO",O_RDONLY), you check for read permission against the file FOO. If this succeeds, you can later read from 'fd' even after FOO's permissions are changed so that you can no longer open FOO for reading. If this tradition were followed here, then when you invoke fd=open("FOODIR", O_EXEC), you should check for search permission against the directory FOODIR. If this succeeds, you can later use openat on 'fd' even if FOODIR's permissions are changed so that you can no longer open FOODIR for searching. (The discussion in this paragraph assumes the O_EXEC change of my 20060302b comment, but a similar point can be made without O_EXEC, with an implementation that always attempts to get execute/search access if it is available, when you open the file.) Alternatively, openat, fstatat, etc., could be defined to check FOODIR's search permissions on each use, rather than when the file descriptor was created. If so, this point should be made clear. There is a similar problem with fdopendir. There is a related problem with fexecve, too. You should have execute permission on the file, but is this determined when the file is opened, or when the file descriptor is executed? The proposed action assumes the Unix tradition, along with the O_EXEC change of my 20060302b comment. If the 20060302b comment is not accepted, then the proposed action could be modified to say something like "valid file descriptor whose corresponding file was accessible to execute/search when the file was opened." If the idea of the Unix tradition is not accepted, then wording needs to be added to all the directory-oriented functions to make it clear that search permission is required on the directory identified by _fd_, that the functions shall fail with errno==EACCES otherwise. Action: Change the directory-access primitives to require that the file descriptor be open for searching, as follows: For openat: Page 24 line 593, after: In this case the file to be opened is determined relative to the directory associated with the file descriptor _fd_ instead of the current working directory. insert: The test for whether _fd_ is searchable is based on whether _fd_ is open for searching, not whether the underlying directory currently permits searches. Page 24 line 606, under EBADF: Change "valid file descriptor" to "valid file descriptor open for searching". Similarly for fchmodat, fchownat, fstatat, futimesat, linkat, mkdirat, mkfifoat, mknodat, readlinkat, renameat (two changes needed under EBADF), symlinkat, and unlinkat. For fdopendir: Page 12 line 269, under EBADF: Change "valid file descriptor" to "valid file descriptor open for searching". For fexecve: Page 13 line 293, under EBADF: Change "valid file descriptor" to "valid file descriptor open for executing". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 26 curtis.smith@simtrol.com Bug in ExtAPI_2.1 renameat (rdvk# 4) {CMS-2} Wed, 1 Mar 2006 19:45:09 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 28 Line: 717 Section: renameat Problem: typo Action: change "diretory" to "directory"