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 name
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
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 by
the
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
+++
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
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 looks
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? glibc
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
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 be an
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 filesystem
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:
- simplify
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 -mm.
Thanks,
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 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
19 matches
Mail list logo
