public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: DervishD <raul@pleyades.net>
To: Kasper Dupont <kasperd@daimi.au.dk>
Cc: jw schultz <jw@pegasys.ws>, Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: About /etc/mtab and /proc/mounts
Date: Tue, 4 Mar 2003 12:16:22 +0100	[thread overview]
Message-ID: <20030304111622.GC42@DervishD> (raw)
In-Reply-To: <3E634916.6AE643EB@daimi.au.dk>

    Hi Kasper and J.W. :)

 Kasper Dupont dixit:
> As long as these options is not yet stored in the kernel, we
> need /etc/mtab. The question is how to get them into the kernel.

    That was my first question. Certainly there should be a way to
tell the kernel those options, but... Do we really need them. As you
said, those options (the user options) are used by mount itself, so
the kernel doesn't need to know them. If we are concerned by the
'user' option, that allows normal users to mount and umount
filesystems, and that option is not in the syscall, I think that it
should be done with other approach. See below.

> Before we can get rid of /etc/mtab we need to agree on how
> to solve those problems. There might be other cases I don't
> know about, where /etc/mtab contains special values.

    In the case of normal users mounting and umounting filesystems,
this could be done throught the use of capabilities, I think. And
surely better methods exist. If we could tell the kernel that some
user 'a' mounted filesystem 'f', then at umount time the umount
syscall will only success if root or 'a' umounts 'f'. The question is
if we can tell it to the kernel. The mount syscall maybe? Maybe a VFS
flag just for this purpose (that seems to be very important). Other
user flats like the permissions, etc... are merely informative and
that info is present in /etc/fstab anyway (usually).

    The loopback issue is more a problem of consistency, I think.

    Raúl

  parent reply	other threads:[~2003-03-04 11:05 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-19 11:21 About /etc/mtab and /proc/mounts DervishD
2003-02-26  9:18 ` Kasper Dupont
2003-02-26 10:26   ` Miquel van Smoorenburg
2003-02-26 11:00     ` Olaf Dietsche
2003-02-26 11:14       ` Måns Rullgård
2003-02-26 11:44         ` Kasper Dupont
2003-02-26 12:16         ` Olaf Dietsche
2003-02-26 12:34           ` Måns Rullgård
2003-02-26 13:39             ` Olaf Dietsche
2003-02-26 13:54               ` Måns Rullgård
2003-02-26 14:23                 ` Olaf Dietsche
2003-02-27  4:14   ` Miles Bader
2003-02-27  6:40     ` Kasper Dupont
2003-02-27  7:03       ` Joseph Wenninger
2003-02-27  8:28         ` Kasper Dupont
2003-03-05  0:03           ` Jamie Lokier
2003-02-27  7:06       ` Miles Bader
2003-02-27  8:25         ` Kasper Dupont
2003-02-27  8:42           ` Miles Bader
2003-02-27  9:21             ` jw schultz
2003-02-27  9:49               ` Miles Bader
2003-02-27 23:33                 ` Kasper Dupont
2003-02-27 12:48               ` Denis Vlasenko
2003-02-27 23:28                 ` Kasper Dupont
2003-02-28  6:15                   ` Denis Vlasenko
2003-03-02 13:04               ` DervishD
2003-03-02 14:16                 ` Kasper Dupont
2003-03-03  1:04                   ` jw schultz
2003-03-03 12:22                     ` Kasper Dupont
2003-03-04  2:02                       ` jw schultz
2003-03-05 12:57                         ` Kasper Dupont
2003-03-06  1:18                           ` jw schultz
2003-03-06 23:30                             ` Kasper Dupont
2003-03-04 11:16                       ` DervishD [this message]
2003-03-04 11:08                   ` DervishD
2003-02-27  9:46             ` Kasper Dupont
2003-02-27  9:58               ` Miles Bader
2003-02-27 12:26                 ` Gabriel Paubert
2003-02-27  7:07       ` Joseph Wenninger
2003-02-27  7:08       ` Dominik Kubla
2003-02-27  8:12         ` Kasper Dupont
2003-02-27  9:11           ` Dominik Kubla
2003-02-27 16:00             ` Horst von Brand
2003-02-27 16:31               ` Christoph Hellwig
2003-02-27 16:40               ` Dominik Kubla
2003-02-27 19:47                 ` Kasper Dupont
2003-02-27 22:13                   ` Valdis.Kletnieks
2003-02-27 22:31                     ` Kasper Dupont
2003-02-27 23:54                       ` Miquel van Smoorenburg
2003-02-28  1:37                         ` Miles Bader
2003-03-02 12:53     ` DervishD
2003-03-02 14:00       ` Kasper Dupont
2003-03-04 11:02         ` DervishD
2003-03-04 12:09           ` Kasper Dupont
2003-03-04 14:53             ` DervishD
2003-03-02 12:51   ` DervishD

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=20030304111622.GC42@DervishD \
    --to=raul@pleyades.net \
    --cc=jw@pegasys.ws \
    --cc=kasperd@daimi.au.dk \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox