Project

General

Profile

Actions

Bug #17548

closed

should userland ceph_llseek do permission checking?

Added by Jeff Layton over 7 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
% Done:

0%

Source:
other
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
libcephfs
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

One of the test failures here:

http://qa-proxy.ceph.com/teuthology/jlayton-2016-10-08_00:13:32-fs-wip-jlayton-cephfs---basic-mira/461616/teuthology.log

...was a case where ceph_lseek got back -EPERM. Looking at the code, _lseek does this:

  if (!may_open(f->inode.get(), f->flags, perms)) {                             
    return -EPERM;                                                              
  }                                                                             

I'm not sure this is correct though. lseek operates on an already-opened fd. The kernel ceph client (and llseek calls in general) do not do permission checking on these calls. Do we need to do that here?

Actions #1

Updated by Patrick Donnelly over 7 years ago

Seems reasonable to remove.

Actions #2

Updated by Greg Farnum over 7 years ago

We probably want to follow the kernel. But when I read the man pages and think about security, it seems like it should check: lseek does expose information about the file state! So, I'm confused.

Actions #3

Updated by Jeff Layton over 7 years ago

So does fstat, and we don't do any special permission checking there either.

I guess my view is that if you're issuing a llseek then you have a valid file descriptor and all the rights that that conveys. One of those is being allowed to reposition your own fd offset. Being able to retrieve attributes on the inode that the fd points to is another.

Actions #4

Updated by Greg Farnum over 7 years ago

But...isn't that insecure by design? Why should we assume an open FD is still valid on a setuid'ed fork(), for instance?

Actions #5

Updated by Jeff Layton over 7 years ago

That's just the way UNIX (and hence POSIX) works. UNIX pipelines require file descriptor inheritance.

I'm not sure what you mean by setuid'ed fork(). fork() just spawns a new process with the same creds as the old. Did you mean calling exec() on a setuid'ed binary?

Actions #6

Updated by Greg Farnum over 7 years ago

Yeah, sorry. I know it's possible for a process to drop permissions somehow or other.

Actions #7

Updated by Jeff Layton over 7 years ago

There are several ways, but yeah...it comes down to being careful to close out old file descriptors (or use O_CLOEXEC when doing opens).

Actions #8

Updated by Greg Farnum over 7 years ago

Actually, now I'm confused. What's the failing test, if this isn't a case users should run into anyway?

Actions #9

Updated by Jeff Layton over 7 years ago

  public void test_lseek() throws Exception {
    /* create a new file */
    String path = makePath();
    int size = 12345;
    int fd = createFile(path, size);
    mount.close(fd);

    /* open and check size */
    fd = mount.open(path, CephMount.O_RDWR, 0);
    long end = mount.lseek(fd, 0, CephMount.SEEK_END);
    mount.close(fd);

    mount.unlink(path);

    assertTrue(size == (int)end);
  }

makePath just generates a random uuid filename. So it looks like the create and open succeeded but then the lseek failed.

Beyond that I'm not sure. Maybe another thread changed permissions on that file?

In any case, this behavior just recently changed in commit be9e43e2da41, which added in that permission check. I'm testing a patch now that removes that check and has the _getattr call in that use f->actor_perms instead.

Actions #10

Updated by Jeff Layton over 7 years ago

  • Assignee deleted (Jeff Layton)
Actions #11

Updated by Jeff Layton over 7 years ago

  • Assignee set to Jeff Layton
Actions #12

Updated by Jeff Layton over 7 years ago

  • Status changed from New to Resolved

Fixed in commit db2e7e0811679b4c284e105536ebf3327cc02ffc.

Actions

Also available in: Atom PDF