linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Sipek <jsipek@fsl.cs.sunysb.edu>
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>,
	Al Viro <viro@ftp.linux.org.uk>,
	ezk@cs.sunysb.edu, dquigley@ic.sunysb.edu, dpquigl@tycho.nsa.gov
Subject: [RFC] Privilege escalation in filesystems
Date: Wed, 9 Aug 2006 17:52:00 -0400	[thread overview]
Message-ID: <20060809215200.GB1882@filer.fsl.cs.sunysb.edu> (raw)

While going though the Unionfs code, Chris Wedgwood commented that it might
make sense to ask the list about temporary privilege escalation in file
systems.

Much like NFS, at times Unionfs has to perform operations as another user.
(See below for details as to when and why this has to happen.)

I'd like to know what the preferred way of doing that is. I noticed that NFS
does a simple assignment:

(fs/nfs/nfs4recover.c:nfs4_save_user)
current->fsuid = 0;
current->fsgid = 0;

Should the capabilities be set/dropped as well? Would it be worth it to
provide some kind of generic way of accomplishing this having file system
messing with current directly?


Unionfs specific details:
-------------------------

Namespace unification requires that there is a way to mark a directory
"opaque" - meaning that lookup/readdir should not merge the objects of this
directory with those of a directory of a lower priority. When one creates a
new, empty directory using mkdir(2), the new directory should be empty
according to POSIX/UNIX. To prevent contents of directories on lower
priority branches from appearing in this newly created directory, the
directory is made opaque.

Suppose we have a union of /mnt/a and /mnt/b that are initially empty. Then
we perform the following steps:

$ cd /union
$ mkdir foo
$ find /union
/union/
/union/foo/
$ find /mnt/
/mnt/
/mnt/a/
/mnt/a/foo/
/mnt/a/foo/.wh.__dir_opaque
/mnt/b/

The .wh.__dir_opaque informs our implementation of Unionfs that the
directory is opaque.

The privilege problem appears when we try to remove the directory foo. If
we have write permission to /union, we should be able to remove any file or
(empty) directory. In the above example, /union/foo is empty.
If the foo is owned by someone else and we don't have write permission to
it, we'll fail to remove the opaque whiteout from foo (.wh.__dir_opaque),
which would in turn prevent us from removing foo itself. If we become a
superuser temporarily, we can remove the whiteout as well as the directory,
and all is well.

Josef "Jeff" Sipek.

-- 
UNIX is user-friendly ... it's just selective about who it's friends are

             reply	other threads:[~2006-08-09 21:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-09 21:52 Josef Sipek [this message]
2006-08-09 22:17 ` [RFC] Privilege escalation in filesystems Trond Myklebust
2006-08-09 22:37   ` Josef Sipek
2006-08-10 18:06 ` Bryan Henderson
2006-08-10 19:29   ` Josef Sipek
2006-08-10 19:45   ` Trond Myklebust
2006-08-10 20:47     ` Josef Sipek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060809215200.GB1882@filer.fsl.cs.sunysb.edu \
    --to=jsipek@fsl.cs.sunysb.edu \
    --cc=dpquigl@tycho.nsa.gov \
    --cc=dquigley@ic.sunysb.edu \
    --cc=ezk@cs.sunysb.edu \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ftp.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).