View Issue Details

IDProjectCategoryView StatusLast Update
00002701003.1(2008)/Issue 7System Interfacespublic2010-07-29 15:16
Reportermstrbill Assigned Toajosey  
PrioritynormalSeverityCommentTypeClarification Requested
Status ResolvedResolutionRejected 
NameWilliam Toth
OrganizationOpen Systems Conformance Center - IBM Austin
User ReferenceWLT-XSH7-1
Sectionunlinkat()
Page Number2154
Line Number68023 - 68026
Interp Status---
Final Accepted Text
Summary0000270: potential problem with unlinkat() O_SEARCH requirements
Descriptionunlinkat() 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 ActionEither remove this O_SEARCH requirment or clarify the intend of this portion of the unlinkat() spec.
TagsNo tags attached.

Activities

drepper

2010-07-01 15:30

reporter   bugnote:0000454

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.

mstrbill

2010-07-21 11:59

reporter   bugnote:0000467

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?

eblake

2010-07-21 12:06

manager   bugnote:0000468

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.

eblake

2010-07-21 20:26

manager   bugnote:0000469

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).

Don Cragun

2010-07-21 20:51

manager   bugnote:0000470

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.

geoffclare

2010-07-29 15:16

manager   bugnote:0000476

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

Issue History

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