> > On Sat, 21 Apr 2007 10:09:42 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> >
> >> > > +static bool permit_umount(struct vfsmount *mnt, int flags)
> >> > > +{
> >> > >
> >> > > ...
> >> > >
> >> > > + return mnt->mnt_uid == current->uid;
> >> > > +}
> >> >
> >> > Yes, this seems very w
v9fs_insert uses v9fs_fid_lookup (which also locks the fid) to get the primary
fid associated with the dentry and destroys the v9fs_fid struct after removing
the file. If another process called v9fs_fid_lookup on the same dentry, it may
wait undefinitely for the fid's lock (as the struct is freed)
Andrew Morton wrote:
On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
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
mou
Andi Kleen <[EMAIL PROTECTED]> writes:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
>> On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>>
>> > Define a new fs flag FS_SAFE, which denotes, that unprivileged
>> > mounting of this filesystem may not constitute a securit
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > Define a new fs flag FS_SAFE, which denotes, that unprivileged
> > mounting of this filesystem may not constitute a security problem.
> >
> > Since most filesystems have
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> On Apr 21 2007 10:57, Eric W. Biederman wrote:
>>
>>> tmpfs!
>>
>>tmpfs is a possible problem because it can consume lots of ram/swap.
>>Which is why it has limits on the amount of space it can consume.
>
> Users can gobble up all RAM and swap already
On 4/21/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
What I described is a supported feature, nothing more and nothing less. It's
also relatively easy to handle this case correctly in glibc, e.g., [...]
This is only useful if the requirement of an ordered /proc/mounts is
part of the kerne
On Friday 20 April 2007 21:17, Ulrich Drepper wrote:
> 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,
On Apr 21 2007 10:57, Eric W. Biederman wrote:
>
>> tmpfs!
>
>tmpfs is a possible problem because it can consume lots of ram/swap.
>Which is why it has limits on the amount of space it can consume.
Users can gobble up all RAM and swap already today. (Unless they are
confined into an rlimit, whi
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> On Apr 21 2007 08:10, Eric W. Biederman wrote:
>>>
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 u
On Apr 21 2007 08:10, Eric W. Biederman wrote:
>>
>>> 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
On Saturday 21 April 2007 14:57, Tetsuo Handa wrote:
> So, you may want customized version of d_namespace_path()?
No. d_namespace_path() returns valid pathnames, just like d_path() does.
Whatever quoting needed can be added to the resulting pathname.
Andreas
-
To unsubscribe from this list: send
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
2.6.21-rc7-new-aops*
New aops patchset against 2.6.21-rc7. I was going to rebase against
-mm and submit the patchset, but I ended up doing quite a lot of new
filesystem conversions and fixes so I stay with mainline so as to
n
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> 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 un
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
>> 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 b
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> 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
Why? This sounds like a left over from when we were checking permissions.
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> 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 u
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> 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
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> 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,
> pre
Hello.
I've just returned from ELC2007 and
I haven't read all posts in this thread yet,
but I want to comment to this function.
> In AppArmor, we are interested in pathnames relative to the namespace root.
> This is the same as d_path() except for the root where the search ends. Add
> a function
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> 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 mou
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Sat, 21 Apr 2007 10:09:42 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
>> > > +static bool permit_umount(struct vfsmount *mnt, int flags)
>> > > +{
>> > >
>> > > ...
>> > >
>> > > +return mnt->mnt_uid == current->uid;
>> > > +}
>> >
>> >
> 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.
I would be very glad if this feature can be disabled on compilation.
Because this feature is fine for desktops, but not for servers. Ano
On Sat, 21 Apr 2007 10:09:42 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > +static bool permit_umount(struct vfsmount *mnt, int flags)
> > > +{
> > >
> > > ...
> > >
> > > + return mnt->mnt_uid == current->uid;
> > > +}
> >
> > Yes, this seems very wrong. I'd have thought that comparing
> > 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.
> I would be very glad if this feature can be disabled on compilation.
> Because this feature is fine for desktops, but not for se
> >
> > > 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 this flag.
> > 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.
>
> How does FUSE do this?
>
> There are obvious cases like crafting a filesystem which has set
> On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > 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
> > mou
> > +static bool permit_umount(struct vfsmount *mnt, int flags)
> > +{
> >
> > ...
> >
> > + return mnt->mnt_uid == current->uid;
> > +}
>
> Yes, this seems very wrong. I'd have thought that comparing user_struct*'s
> would get us a heck of a lot closer to being able to support aliasing of
> UI
> > 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 M
Andrew Morton wrote:
On Fri, 20 Apr 2007 12:25:34 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
+static bool permit_umount(struct vfsmount *mnt, int flags)
+{
...
+ return mnt->mnt_uid == current->uid;
+}
Yes, this seems very wrong. I'd have thought that comparing user_struct*'s
wo
On Fri, 20 Apr 2007 12:25:35 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> 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
On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> 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,
On Fri, 20 Apr 2007 12:25:40 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> 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.
How does FUSE do this?
Th
On Fri, 20 Apr 2007 12:25:34 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> +static bool permit_umount(struct vfsmount *mnt, int flags)
> +{
>
> ...
>
> + return mnt->mnt_uid == current->uid;
> +}
Yes, this seems very wrong. I'd have thought that comparing user_struct*'s
would get us a he
On Fri, 20 Apr 2007 12:25:33 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> 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 th
36 matches
Mail list logo
