All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niels de Vos <ndevos@redhat.com>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [RFC] mount: overwrite options from /etc/fstab when given on the commandline
Date: Wed, 01 Aug 2012 12:11:00 +0200	[thread overview]
Message-ID: <501900B4.9040604@redhat.com> (raw)
In-Reply-To: <20120801094833.GC1019@x2.net.home>

On 08/01/2012 11:48 AM, Karel Zak wrote:
 > On Wed, Aug 01, 2012 at 11:11:41AM +0200, Niels de Vos wrote:
 >> it seems that some of the options given in /etc/fstab are not overloaded by
 >> options given on the mount-commandline.
 >
 > Well, all depends on kernel (and FS driver) how mount options are
 > evaluated. We have no any strict rules for 'source' and 'mount
 > options' in the mount(2) syscall.
 >
 > The generic convention (!= rule) is that the option overwrites an
 > option previously specified in the mount options string:
 >
 >      aaa=x,bbb,aaa=y     ->  aaa should be 'y'
 >
 > This is reason why mount(8) only appends the options from command line
 > to the options string from fstab.
 >
 > Anyway, depends on FS driver how the options string will be
 > interpreted -- for example btrfs supports duplicate device= mount
 > option.

Ah, okay, if there are valid use-cases for options to be listed multiple
times, it won't be possible to overload the options from /etc/fstab by the
options from the commandline.

 >> Some options are not allowed to be
 >> passed multiple times (like the SElinux context options) and mounting will fail
 >> if options are present in both /etc/fstab and on the commandline.
 >
 > This is stupid SELinux disadvantage and SELinux should be fixed.

Yeah, sounds like it. I may have a look on how the kernel can handle the
SElinux options better.

 >> Is there a reason for not overloading the options from /etc/fstab by the
 >> options given on the commandline?
 >>
 >> The patch below changes the behaviour of mount so that options on the
 >> commandline replace options given in /etc/fstab.
 >
 > I'd like to avoid that mount(8) tries to understand filesystem specific
 > options. The command mount(8) has no clue about the options (non-VFS
 > options). For example:
 >
 > fstab:
 >      /dev/sda    /mnt    btrfs   device=/dev/sdb     0   0
 >
 > command line:
 >
 >      mount /mnt -o device=/dev/sdc,device=/dev/sdd
 >
 >
 > so the final mount options string:
 >
 >      device=/dev/sdb,device=/dev/sdc,device=/dev/sdd
 >
 > .. and this all is pretty valid for btrfs.

Nice example!

 > I'd like to implement for the next release 2.23 a new command line
 > options to specify a way how compose the final options string in the
 > mount(8). It's already in our Documentation/TODO file, see
 > --options-mode, probably something like:
 >
 >      --options-mode={ignore,append,prepend,replace,dedup}
 >
 > or so.

Hmm, that sounds like it'll solve the problem, unless you'r combining
SElinux contexts and btrsf...

Thanks for your detailed response,
Niels

      parent reply	other threads:[~2012-08-01 10:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-01  9:11 [RFC] mount: overwrite options from /etc/fstab when given on the commandline Niels de Vos
2012-08-01  9:48 ` Karel Zak
2012-08-01 10:03   ` Karel Zak
2012-08-01 10:14     ` Niels de Vos
2012-08-01 10:32       ` Karel Zak
2012-08-01 11:58         ` Niels de Vos
2012-08-01 17:08           ` Karel Zak
2012-08-02  9:46             ` Niels de Vos
2012-08-01 10:11   ` Niels de Vos [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=501900B4.9040604@redhat.com \
    --to=ndevos@redhat.com \
    --cc=kzak@redhat.com \
    --cc=util-linux@vger.kernel.org \
    /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.