View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000270 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2010-06-25 19:45 | 2010-07-29 15:16 |
| Reporter | mstrbill | Assigned To | ajosey | ||
| Priority | normal | Severity | Comment | Type | Clarification Requested |
| Status | Resolved | Resolution | Rejected | ||
| Name | William Toth | ||||
| Organization | Open Systems Conformance Center - IBM Austin | ||||
| User Reference | WLT-XSH7-1 | ||||
| Section | unlinkat() | ||||
| Page Number | 2154 | ||||
| Line Number | 68023 - 68026 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0000270: potential problem with unlinkat() O_SEARCH requirements | ||||
| Description | unlinkat() has the following requirement: If the file descriptor was opened without O_SEARCH, the function shall check whether directory searches are permitted using the current permissions of the directory underlying the file descriptor. If the file descriptor was opened with O_SEARCH, the function shall not perform the check. We think that the latter requirement to not perform the directory search when O_SEARCH is a potential security exposure. It seems to be a security flaw to let users unlink a file when they don't have permission to remove that particular file. Our implementation calls a kernel function to remove the file. We and other implementations(which should have the same problem) would to have to write this function to ignore the permission. | ||||
| Desired Action | Either remove this O_SEARCH requirment or clarify the intend of this portion of the unlinkat() spec. | ||||
| Tags | No tags attached. | ||||
|
|
The caller first has to get a file descriptor opened with O_SEARCH permission. To get this the same privileges as before are needed for a successful open call. Only once you have the descriptor the tests are relaxed. This is the same for all *at functions. The group does not see where there is a security problem since getting a file descriptor with the appropriate permission and possibly passing it on is an explicit act. If you disagree provide a description of a complete scenario where you think the problem is visible. |
|
|
More specifically, the standard doesn't seem to describe what happens if the directory permissions change between the open() and unlinkat() calls. Should we ignore the new permissions in favor of the permissions at the open() call? |
|
|
The fact that the fd was opened with O_SEARCH at open() time means that the user owning the fd has search rights, even if the directory currently would not have those same rights if opened afresh. This works in the same way that you can use open(file,O_CREAT|O_WRONLY,0) and still write to the the fd, even though the permissions of that file prevent anyone else from writing to it if opened afresh. So yes, it is possible to unlink files using an fd with O_SEARCH rights that could not otherwise be unlinked, but this is not a security hole, because you could have only obtained such an fd from a previous point in time where the open() would not reject the request for O_SEARCH rights. |
|
|
Another point to note. XSH line 22172 states: "The effect on file descriptors for files open at the time of a call to chmod( ) is implementation-defined." Therefore, it is permissible for an implementation of chmod() used to drop search rights on a directory to simultaneously cause a drop of search rights for all processes that have an fd visiting that directory, provided that this is documented as part of the implementation. In other words, you have a back-door escape of using chmod() to guarantee that if an fd has O_SEARCH permissions, then stat() on the directory would also show search rights, so unlinkat() can effectively ignore O_SEARCH and use current permissions instead (although I'm not sure that it would be any easier to implement dropping the O_SEARCH rights across all processes with open fds visiting a directory during chmod, nor whether this back-door was intended). |
|
|
The quote in 0000270:0000469 seems to be missing some context. The APPLICATION USAGE on P657, L22261-22264 says this exception should not apply in conforming environments, but can happen on stateless filesystems (e.g., NFS). I believe that the intent of the authors of this part of the standard is accurately described in the APPLICATION USAGE and that the normative text in the DESCRIPTION needs to be updated to close this loophole. |
|
|
In the 29th July teleconference the group decided to reject this aardvark and submit a new one on the separate chmod() issue raised in 0000270:0000469 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-06-25 19:45 | mstrbill | New Issue | |
| 2010-06-25 19:45 | mstrbill | Status | New => Under Review |
| 2010-06-25 19:45 | mstrbill | Assigned To | => ajosey |
| 2010-06-25 19:45 | mstrbill | Name | => William Toth |
| 2010-06-25 19:45 | mstrbill | Organization | => Open Systems Conformance Center - IBM Austin |
| 2010-06-25 19:45 | mstrbill | User Reference | => WLT-XSH7-1 |
| 2010-06-25 19:45 | mstrbill | Section | => unlinkat() |
| 2010-06-25 19:45 | mstrbill | Page Number | => 2154 |
| 2010-06-25 19:45 | mstrbill | Line Number | => 68023 - 68026 |
| 2010-07-01 15:30 | drepper | Note Added: 0000454 | |
| 2010-07-21 11:59 | mstrbill | Note Added: 0000467 | |
| 2010-07-21 12:06 | eblake | Note Added: 0000468 | |
| 2010-07-21 20:26 | eblake | Note Added: 0000469 | |
| 2010-07-21 20:51 | Don Cragun | Note Added: 0000470 | |
| 2010-07-29 15:16 | geoffclare | Interp Status | => --- |
| 2010-07-29 15:16 | geoffclare | Note Added: 0000476 | |
| 2010-07-29 15:16 | geoffclare | Status | Under Review => Resolved |
| 2010-07-29 15:16 | geoffclare | Resolution | Open => Rejected |
