linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: Question regarding shared subtree mount flags.
Date: Wed, 29 Feb 2012 13:59:49 +0800	[thread overview]
Message-ID: <20120229055949.GA5030@ram-ThinkPad-T61> (raw)
In-Reply-To: <201202282233.EJF00063.VLFOSFMtJQOHFO@I-love.SAKURA.ne.jp>

On Tue, Feb 28, 2012 at 10:33:15PM +0900, Tetsuo Handa wrote:
> I noticed that TOMOYO's mount flag checking priority
> 
>         if (flags & MS_REMOUNT) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_REMOUNT];
>                 flags &= ~MS_REMOUNT;
>         }
>         if (flags & MS_MOVE) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_MOVE];
>                 flags &= ~MS_MOVE;
>         }
>         if (flags & MS_BIND) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_BIND];
>                 flags &= ~MS_BIND;
>         }
>         if (flags & MS_UNBINDABLE) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_UNBINDABLE];
>                 flags &= ~MS_UNBINDABLE;
>         }
>         if (flags & MS_PRIVATE) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_PRIVATE];
>                 flags &= ~MS_PRIVATE;
>         }
>         if (flags & MS_SLAVE) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_SLAVE];
>                 flags &= ~MS_SLAVE;
>         }
>         if (flags & MS_SHARED) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_SHARED];
>                 flags &= ~MS_SHARED;
>         }
>         if (!type)
>                 type = "<NULL>";
>         idx = tomoyo_read_lock();
>         error = tomoyo_mount_acl(&r, dev_name, path, type, flags);
>         tomoyo_read_unlock(idx);
> 
> is wrong and it need to follow priority used by do_mount().
> 
>         if (flags & MS_REMOUNT)
>                 retval = do_remount(&path, flags & ~MS_REMOUNT, mnt_flags,
>                                     data_page);
>         else if (flags & MS_BIND)
>                 retval = do_loopback(&path, dev_name, flags & MS_REC);
>         else if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
>                 retval = do_change_type(&path, flags);
>         else if (flags & MS_MOVE)
>                 retval = do_move_mount(&path, dev_name);
> 
> I got a question regarding priority among MS_SHARED, MS_PRIVATE, MS_SLAVE and
> MS_UNBINDABLE. I'm wondering which flag TOMOYO should use for permission check
> if more than one of MS_SHARED, MS_PRIVATE, MS_SLAVE or MS_UNBINDABLE is passed.
> 
>   commit 07b20889 "[PATCH] beginning of the shared-subtree proper"
>   commit 03e06e68 "[PATCH] introduce shared mounts"
>   commit a58b0eb8 "[PATCH] introduce slave mounts"
>   commit 9676f0c6 "[PATCH] unbindable mounts"
> 
> introduced these flags and
> 
>   commit 7a2e8a8f "VFS: Sanity check mount flags passed to change_mnt_propagation()"
> 
> clarified that these flags must be exclusively passed.

right. It makes more sense for a user to change a vfsmount to one type at a given
time.

> 
> Commit 7a2e8a8f went to 2.6.36 but has not gone to 2.6.27 nor 2.6.32.
> Is this simply because commit 7a2e8a8f was not proposed for backporting?

looks like it. No one saw the need to backport that patch.

> 
> If so, is security_sb_mount() allowed to return -EINVAL if more than one of
> these flags are passed (like shown below) so that TOMOYO will not generate
> inaccurate audit logs?
> 
>         if (flags & MS_REMOUNT) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_REMOUNT];
>                 flags &= ~MS_REMOUNT;
>         } else if (flags & MS_BIND) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_BIND];
>                 flags &= ~MS_BIND;
>         } else if (flags & MS_SHARED) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_SHARED];
>                 flags &= ~MS_SHARED;
>                 if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
>                         return -EINVAL;
>         } else if (flags & MS_PRIVATE) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_PRIVATE];
>                 flags &= ~MS_PRIVATE;
>                 if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
>                         return -EINVAL;
>         } else if (flags & MS_SLAVE) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_SLAVE];
>                 flags &= ~MS_SLAVE;
>                 if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
>                         return -EINVAL;
>         } else if (flags & MS_UNBINDABLE) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_MAKE_UNBINDABLE];
>                 flags &= ~MS_UNBINDABLE;
>                 if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
>                         return -EINVAL;
>         } else if (flags & MS_MOVE) {
>                 type = tomoyo_mounts[TOMOYO_MOUNT_MOVE];
>                 flags &= ~MS_MOVE;
>         }

I  think that is right. However the code can be further reorganized to check for
(MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE) only ones, instead of checking
under every else if.

RP

>         if (!type)
>                 type = "<NULL>";
>         idx = tomoyo_read_lock();
>         error = tomoyo_mount_acl(&r, dev_name, path, type, flags);
>         tomoyo_read_unlock(idx);


      reply	other threads:[~2012-02-29  6:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-28 13:33 Question regarding shared subtree mount flags Tetsuo Handa
2012-02-29  5:59 ` Ram Pai [this message]

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=20120229055949.GA5030@ram-ThinkPad-T61 \
    --to=linuxram@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    /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).