> As far as I can see, glibc internally looks at /proc/mounts (or else mtab) to
> find out where tmpfs is mounted for opening files there, and to look up
> filesystem information for statfs(), while accessing that path, too. Fstatfs()
> also looks into the same files, but it only matches by filesys
On Fri, 20 Apr 2007 01:23:04 +0200
Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> First, when __d_path() hits a lazily unmounted mount point, it tries to
> prepend
> the name of the lazily unmounted dentry to the path name. It gets this wrong,
> and also overwrites the slash that separates the
> There is some disagreement what /proc/mounts should include. Currently it
> reports all mounts from the current namespace and doesn't include lazy
> unmounts. This leads to ambiguities with the rootfs (which is an internal
> mount
> irrelevant to user-space except in the initrd), and in chroots.
From: Miklos Szeredi <[EMAIL PROTECTED]>
The owner doesn't need sysadmin capabilities to call umount().
Similar behavior as umount(8) on mounts having "user=UID" option in
/etc/mtab. The difference is that umount also checks /etc/fstab,
presumably to exclude another mount on the same mountpoint.
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add ownership information to mounts.
A new mount flag, MS_SETUSER is used to make a mount owned by a user.
If this flag is specified, then the owner will be set to the current
real user id and the mount will be marked with the MNT_USER flag. On
remount do
From: Miklos Szeredi <[EMAIL PROTECTED]>
Allow clone_mnt() to return errors other than ENOMEM. This will be
used for returning a different error value when the number of user
mounts goes over the limit.
Fix copy_tree() to return EPERM for unbindable mounts.
Don't propagate further from dup_mnt_
From: Miklos Szeredi <[EMAIL PROTECTED]>
Allow bind mounts to unprivileged users if the following conditions
are met:
- mountpoint is not a symlink or special file
- parent mount is owned by the user
- the number of user mounts is below the maximum
Unprivileged mounts imply MS_SETUSER, and
From: Miklos Szeredi <[EMAIL PROTECTED]>
Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
FUSE was designed from the beginning to be safe for unprivileged
users. This has also been verified in practice over many years. In
addition unprivileged mounts require the parent mount to be owned b
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add sysctl variables for accounting and limiting the number of user
mounts.
The maximum number of user mounts is set to 1024 by default. This
won't in itself enable user mounts, setting a mount to be owned by a
user is first needed
Signed-off-by: Miklos
From: Miklos Szeredi <[EMAIL PROTECTED]>
Define a new fs flag FS_SAFE, which denotes, that unprivileged
mounting of this filesystem may not constitute a security problem.
Since most filesystems haven't been designed with unprivileged
mounting in mind, a thorough audit is needed before setting thi
This patchset has now been bared to the "lowest common denominator"
that everybody can agree on. Or at least there weren't any objections
to this proposal.
Andrew, please consider it for -mm.
Thanks,
Miklos
v3 -> v4:
- simplify interface as much as possible, now only a single option
(
From: Miklos Szeredi <[EMAIL PROTECTED]>
Declarations go into headers.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/super.c
===
--- linux.orig/fs/super.c 2007-04-20 11:55:02.0 +0200
+++ linux/f
I am trying to use relayFS from an interrupt context. I read the
documentation and downloaded and ran successfully the examples from
http://relayfs.sourceforge.net.
I am running on Fedora 6 machine with 2.6.18-1.2798.fc6 kernel (no patches).
I have two years of experience in linux kernel programm
On Friday 20 April 2007 11:30, Alan Cox wrote:
> > As far as I can see, glibc internally looks at /proc/mounts (or else
> > mtab) to find out where tmpfs is mounted for opening files there, and to
> > look up filesystem information for statfs(), while accessing that path,
> > too. Fstatfs() also lo
On Wed, Apr 18, 2007 at 07:06:00AM -0600, Andreas Dilger wrote:
> On Apr 17, 2007 18:25 +0530, Amit K. Arora wrote:
> > On Fri, Mar 30, 2007 at 02:14:17AM -0500, Jakub Jelinek wrote:
> > > Wouldn't
> > > int fallocate(loff_t offset, loff_t len, int fd, int mode)
> > > work on both s390 and ppc/arm
On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
Yes, that one, sorry. The values it obtains that way are not reliable.
Why should the mount point info together with the filesystem type not
be reliable? You're trying to find an excuse to break tings, that
seems all there is.
-
To uns
On Fri, Apr 20, 2007 at 07:21:46PM +0530, Amit K. Arora wrote:
> Ok.
> In this case we may have to consider following things:
>
> 1) Obviously, for this glibc will have to call fallocate() syscall with
> different arguments on s390, than other archs. I think this should be
> doable and should not
On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
Possibly for fstatfs(): fstatfs() has no way of looking up mount points per
path name in /proc/mounts, and so it resorts to mapping from the numeric
statfs->f_type to the filesystem name (e.g., "ext3"), looks up the first
mount point with
On Friday 20 April 2007 17:15, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> > Possibly for fstatfs(): fstatfs() has no way of looking up mount points
> > per path name in /proc/mounts, and so it resorts to mapping from the
> > numeric statfs->f_type to the fi
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> This patchset has now been bared to the "lowest common denominator"
> that everybody can agree on. Or at least there weren't any objections
> to this proposal.
>
> Andrew, please consider it for -mm.
>
> Thanks,
> Miklos
>
>
> v3 -> v4:
>
> -
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Miklos Szeredi ([EMAIL PROTECTED]):
>> This patchset has now been bared to the "lowest common denominator"
>> that everybody can agree on. Or at least there weren't any objections
>> to this proposal.
>>
>> Andrew, please consider it for -m
On Friday 20 April 2007 17:24, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> > Yes, that one, sorry. The values it obtains that way are not reliable.
>
> Why should the mount point info together with the filesystem type not
> be reliable?
Ah ... I overlooked
On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
The code also seems to stop at the first matching mount point. You can have
the same device mounted on the same mount point multiple times but with
different mount options, e.g., [...]
You can unfortunately do many stupid things. That'
On Thu, 19 Apr 2007, Stephen Smalley wrote:
already happened to integrate such support into userland.
To look at it in a slightly different way, the AA emphasis on not
modifying applications could be viewed as a limitation. Ultimately,
users have security goals that go beyond just what the OS
On Fri, 2007-04-20 at 11:45 -0700, David Lang wrote:
> On Thu, 19 Apr 2007, Stephen Smalley wrote:
>
> > already happened to integrate such support into userland.
> >
> > To look at it in a slightly different way, the AA emphasis on not
> > modifying applications could be viewed as a limitation.
> > I gave a chroot example that showed that in the current
> > implementation, you can get pretty random clashes between mounts; there are
> > other cases with lazy unmounts as well.
>
> Irrelevant as well. If you create chroot problems it's your problem.
>
> The fact is that if you have a norm
One of my autoboot test clients gave me this during shutdown. It used
reiserfs and autofs and NFS heavily.
Unmounting file systems
BUG: Dentry 8100f3693a40{i=2352220,n=xattrs} still in use (1) [unmount of
reiserfs sda9]
[ cut here ]
kernel BUG at
/mnt/dm-2/newautoboo
27 matches
Mail list logo
