linux-kernel - Re: Adding subroot information to /proc/mounts, or obtaining that through other means

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1I1KA8-0007Fu-00@dorka.pomaz.szeredi.hu>
Date:	Thu, 21 Jun 2007 12:45:16 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	nix@...eri.org.uk
CC:	hpa@...or.com, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, util-linux-ng@...r.kernel.org
Subject: Re: Adding subroot information to /proc/mounts, or obtaining that through other means

> > Right now it is actually impossible to conclusively determine a
> > filesystem-relative path in the presence of bind (and possibly move)
> > mounts.  This is highly desirable to be able to do in contexts that
> > involve non-Linux (or not-the-current-instance-of-Linux) accesses to the
> > filesystem, e.g. other filesystems or bootloaders.
> 
> It's also highly desirable if you want to be able to run a backup :) one
> would desire to back up the filesystem as a whole, not some bind mount
> of one directory out of it (and backing up both is needless
> duplication).
> 
> So I applaud this and would be an immediate user, no matter what format
> is chosen, as long as we can tell what is mounted where.
> 
> (As an aside, it would be nice if mount(8) could supply (a limited
> amount of) extra (arbitrary?) textual options to the kernelq,
> specifically so that mount options which are only interpreted by
> userspace programs, like `user' and the quota options, could appear in
> /proc/mounts. That way we could finally ditch bloody /etc/mtab for good.

I'm working on this actually.  See this (and related patches) in -mm:

  http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/broken-out/unprivileged-mounts-add-user-mounts-to-the-kernel.patch

This solves the "user=" thing, but is not a generic solution for other
options.  And I'm wondering if there is really a need for that.

Which quota options are you thinking about?  Some quota options
(e.g. for ext*) seem to be already present in /proc/mounts.

There's also "loop=", but that's not really a per-mount option, but a
per-loop-device option, so it could be stored separately under /var.

Do you know any other options which are only in /etc/mtab, and need to
be stored along with each mount?

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/