All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: ebiederm@xmission.com, akpm@linux-foundation.org,
	hch@infradead.org, viro@ZenIV.linux.org.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: unprivileged mounts git tree
Date: Fri, 5 Sep 2008 10:31:34 -0500	[thread overview]
Message-ID: <20080905153134.GA18367@us.ibm.com> (raw)
In-Reply-To: <E1KbGwb-0002rl-49@pomaz-ex.szeredi.hu>

Quoting Miklos Szeredi (miklos@szeredi.hu):
> On Thu, 04 Sep 2008, Miklos Szeredi wrote:
> > On Thu, 4 Sep 2008, Serge E. Hallyn wrote:
> > > Are you going to revert the change forcing CL_SLAVE for
> > > !capable(CAP_SYS_ADMIN)?  I don't think we want that - I think that
> > > *within* a set of user mounts, propagation should be safe, right?
> > > 
> > > Will you be able to do this soon?  If not, should we just do the part
> > > returning -EPERM when turning a shared mount into a user mount? 
> > 
> > OK, let's do that first and the tricky part (propagation vs. user
> > mounts) later.  Will push after I've tested it.
> 
> Here it is:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git unprivileged-mounts
> 
> I don't know what's next, this patchset has been in and out of -mm for
> as long as I can remember, but it hasn't generated much interest
> outside the two of us :)
> 
> I do think this is an important feature though, even if not as sexy as
> some other things.
> 
> Al?  Is there any chance of this making it to 2.6.28?
> 
> Thanks,
> Miklos

Ok I should take the time to properly add these to ltp, but for now here
is the result of 15-minutes of playing around with shell scripts to do
some basic testing.

Run usermounts_root.sh as root first, then usermounts_user as a user.
Cleanup for the usermounts_root.sh side-effects is not done.

Miklos, do you have better-thought-out or more complete testcases?

-serge

=====================================================================
FILE usermounts_root.sh
=====================================================================
#!/bin/sh
MMOUNTDIR=/usr/src/mmount-0.3
MOUNT=${MMOUNTDIR}/mmount
UMOUNT=${MMOUNTIDR}/ummount

mkdir -p /mnt/shared /mnt/slave /mnt/private
mkdir /mnt/shared/d /mnt/slave/d /mnt/private/d

touch /mnt/shared/a
touch /mnt/slave/b
touch /mnt/private/c

mount --bind /mnt/shared /mnt/shared
mount --make-rshared /mnt/shared
mount --bind /mnt/shared /mnt/slave
mount --make-rslave /mnt/slave
=====================================================================


=====================================================================
FILE usermounts_user.sh
=====================================================================
#!/bin/sh
MMOUNTDIR=/usr/src/mmount-0.3
MOUNT=${MMOUNTDIR}/mmount
UMOUNT=${MMOUNTDIR}/ummount

mkdir t1

# user bind a root shared mount.  Should fail -EPERM.

$MOUNT --bind /mnt/shared t1
rc=$?
if [ $rc -eq 0 ]; then
	echo "FAIL: succeeded in user-binding a root-shared dir"
	exit 1
fi
echo "PASS: first test passed (refused to user-bind a root-shared dir"

# user bind a root shared mount, then bind into there.  Make sure
# that the two binds work, and the second is not propagated to the
# first

$MOUNT --bind /mnt/slave t1
$MOUNT --bind /mnt/private t1/d
if [ ! -f t1/d/c ]; then
	echo "failed mounting private under slave/d"
	exit 1
fi
if [ -f /mnt/slave/d/c ]; then
	echo "user mount of private under slave/d was propagated to /mnt/slave!"
	exit 1
fi
if [ -f /mnt/shared/d/c ]; then
	echo "user mount of private under slave/d was propagated to /mnt/shared!"
	exit 1
fi

ret=0
$UMOUNT t1/d || ret=1
$UMOUNT t1 || ret=1
if [ $ret -eq 1 ]; then
	echo "user umount refused in second test"
	exit 1
fi
if [ -f t1/a ]; then
	echo "user umount failed in second test"
	exit 1
fi

rmdir t1

echo "PASS: second test passed (user-mounts of root-slave and root-private dirs)"

# bind mount /etc/shadow.  First make sure that we cannot read
# /etc/shadow and can read the target.  Then make sure that we
# can no longer read the target after the bind mount.

cat /etc/shadow >> /dev/null
rc=$?
if [ $rc -eq 0 ]; then
	echo "test 3: Oh no, I'm able to read /etc/shadow!"
	exit 1
fi
echo ab > t1
cat t1 >> /dev/null
rc=$?
if [ $rc -ne 0 ]; then
	echo "test 3: Odd, couldn't read my own file."
	exit 1
fi
$MOUNT --bind /etc/shadow t1
cat t1 >> /dev/null
rc=$?
if [ $rc -eq 0 ]; then
	echo "test 3: bind mount of /etc/shadow gave me read access!"
	exit 1
fi
$UMOUNT t1
rm t1

echo "PASS: third test passed (user mount of file)"

echo "all tests succeeded"
exit 0
=====================================================================

  parent reply	other threads:[~2008-09-05 15:31 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-07 12:05 unprivileged mounts git tree Miklos Szeredi
2008-08-07 22:27 ` Serge E. Hallyn
2008-08-08  0:07   ` Eric W. Biederman
2008-08-08  0:25     ` Serge E. Hallyn
2008-08-25 11:01       ` Miklos Szeredi
2008-08-27 15:36         ` Serge E. Hallyn
2008-08-27 15:55           ` Miklos Szeredi
2008-08-27 18:46             ` Serge E. Hallyn
2008-09-03 18:45               ` Miklos Szeredi
2008-09-03 21:54                 ` Serge E. Hallyn
2008-09-03 22:02                 ` Serge E. Hallyn
2008-09-03 22:25                   ` Miklos Szeredi
2008-09-03 22:43                     ` Serge E. Hallyn
2008-09-04  6:42                       ` Miklos Szeredi
2008-09-04 13:28                         ` Serge E. Hallyn
2008-09-04 14:06                           ` Miklos Szeredi
2008-09-04 15:40                             ` Miklos Szeredi
2008-09-04 16:17                               ` Serge E. Hallyn
2008-09-04 17:42                                 ` Miklos Szeredi
2008-09-04 17:48                                   ` Serge E. Hallyn
2008-09-04 18:03                                     ` Miklos Szeredi
2008-09-04 18:49                                       ` Serge E. Hallyn
2008-09-04 22:26                                         ` Miklos Szeredi
2008-09-04 23:32                                           ` Serge E. Hallyn
2008-09-05 15:31                               ` Serge E. Hallyn [this message]
2008-09-09 13:34                                 ` Miklos Szeredi
2008-09-11 10:37                                   ` Eric W. Biederman
2008-09-11 14:43                                     ` Miklos Szeredi
2008-09-11 15:20                                       ` Serge E. Hallyn
2008-09-11 15:44                                         ` Miklos Szeredi
2008-09-11 18:54                                         ` Eric W. Biederman
2008-09-12 22:08                                           ` Serge E. Hallyn
2008-09-13  3:12                                             ` Eric W. Biederman
2008-09-14  1:56                                               ` Serge E. Hallyn
2008-09-14  3:06                                                 ` Eric W. Biederman
2008-09-30 19:39                                                   ` Serge E. Hallyn
2008-10-06 11:05                                                     ` Miklos Szeredi
2008-09-11 19:04                                       ` Eric W. Biederman
2008-09-11 19:58                                         ` Eric W. Biederman

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=20080905153134.GA18367@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=viro@ZenIV.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.