On Jan 8, 2008 8:40 PM, Al Boldi <[EMAIL PROTECTED]> wrote:
> Rik van Riel wrote:
> > Al Boldi <[EMAIL PROTECTED]> wrote:
> > > Has there been some thought about an incremental fsck?
> > >
> > > You know, somehow fencing a sub-dir to do an online fsck?
> >
> > Search for "chunkfs"
>
> Sure, and the
Hello.
[EMAIL PROTECTED] wrote:
> Good summary - probably should add that to the patch, drop it into
> Documentation/syaoran-config.txt or similar...
I see.
> Modification while reading *is* an issue, but can probably be worked around
> with some clever locking. The race condition I was thinking
On Tue, 08 Jan 2008 22:50:43 +0900, Tetsuo Handa said:
> Yes. It is a line-by-line processable format defined as:
>
> filename permission owner group flags type [ symlink_data | major minor ]
>
> where flags are bit-wised combinations of
>
> * 1: Allow creation of the file.
> * 2: Allow
Rik van Riel wrote:
> Al Boldi <[EMAIL PROTECTED]> wrote:
> > Has there been some thought about an incremental fsck?
> >
> > You know, somehow fencing a sub-dir to do an online fsck?
>
> Search for "chunkfs"
Sure, and there is TileFS too.
But why wouldn't it be possible to do this on the current
Hello.
Indan Zupancic wrote:
> I think you focus too much on your way of enforcing filename/attributes
> pairs.
So?
> The same can be achieved by creating the device nodes with
> expected attributes, and preventing processes from changing those files.
The device nodes have to be deletable if some
Hi.
Miklos Szeredi wrote:
>> On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
>>> 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 ve
On Tue 2008-01-08 23:42:20, Miklos Szeredi wrote:
> > On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
> > > 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 us
> On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
> > 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 ma
On Tue 2008-01-08 12:35:03, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> This patchset adds support for keeping mount ownership information in the
> kernel, and allow unprivileged mount(2) and umount(2) in certain cases.
>
> The mount owner has the following privileges:
>
On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
> 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 addit
On Tue 2008-01-08 12:35:03, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> This patchset adds support for keeping mount ownership information in the
> kernel, and allow unprivileged mount(2) and umount(2) in certain cases.
>
> The mount owner has the following privileges:
>
> Andi Kleen wrote:
>> Theodore Tso <[EMAIL PROTECTED]> writes:
>> > Now, there are good reasons for doing periodic checks every N mounts
>> > and after M months. And it has to do with PC class hardware. (Ted's
>> > aphorism: "PC class hardware is cr*p").
>>
>> If these reasons are good ones (som
On Wed, 9 Jan 2008 00:22:55 +0300
Al Boldi <[EMAIL PROTECTED]> wrote:
> Has there been some thought about an incremental fsck?
>
> You know, somehow fencing a sub-dir to do an online fsck?
Search for "chunkfs"
--
All rights reversed.
-
To unsubscribe from this list: send the line "unsubscribe
On Tue, 8 Jan 2008, Miklos Szeredi wrote:
> > On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> > > +static int reserve_user_mount(void)
> > > +{
> > > + int err = 0;
> > > +
> > > + spin_lock(&vfsmount_lock);
> > > + if (nr_user_mounts >= max_user_mounts && !capable(CAP
> > @@ -510,10 +533,16 @@ static struct vfsmount *clone_mnt(struct
> > int flag)
> > {
> > struct super_block *sb = old->mnt_sb;
> > - struct vfsmount *mnt = alloc_vfsmnt(old->mnt_devname);
> > + struct vfsmount *mnt;
> >
> > + if
> On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> > plain text document attachment
> > (unprivileged-mounts-account-user-mounts.patch)
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > Add sysctl variables for accounting and limiting the number of user
> > mounts.
> ...
> > +int nr_u
On Tue, 2008-01-08 at 20:08 +0100, Miklos Szeredi wrote:
>
> The logic behind EPERM, is that this failure is only for unprivileged
> callers. ENOMEM is too specifically about OOM. It could be changed
> to ENOSPC, ENFILE, EMFILE, or it could remain EPERM. What do others
> think?
Since you're p
> On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> > +static int reserve_user_mount(void)
> > +{
> > + int err = 0;
> > +
> > + spin_lock(&vfsmount_lock);
> > + if (nr_user_mounts >= max_user_mounts && !capable(CAP_SYS_ADMIN))
> > + err = -EPERM;
> > +
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> @@ -510,10 +533,16 @@ static struct vfsmount *clone_mnt(struct
> int flag)
> {
> struct super_block *sb = old->mnt_sb;
> - struct vfsmount *mnt = alloc_vfsmnt(old->mnt_devname);
> +
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> plain text document attachment
> (unprivileged-mounts-account-user-mounts.patch)
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Add sysctl variables for accounting and limiting the number of user
> mounts.
...
> +int nr_user_mounts;
> +int
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> +static int reserve_user_mount(void)
> +{
> + int err = 0;
> +
> + spin_lock(&vfsmount_lock);
> + if (nr_user_mounts >= max_user_mounts && !capable(CAP_SYS_ADMIN))
> + err = -EPERM;
> + else
> +
Mike Frysinger, le Tue 08 Jan 2008 10:31:04 -0500, a écrit :
> with all the non-linux changes that have gone in, does there need to be
> header
> checks here and then have mount.c key off of them ? i'm thinking so ...
Sure!
Samuel
-
To unsubscribe from this list: send the line "unsubscribe lin
Hi Tetsuo,
I think you focus too much on your way of enforcing filename/attributes
pairs. The same can be achieved by creating the device nodes with
expected attributes, and preventing processes from changing those files.
This because expected combinations are known beforehand. And once
those file
On Tuesday 08 January 2008, Miklos Szeredi wrote:
> --- util-linux-ng.orig/configure.ac 2008-01-07 21:40:22.0 +0100
> +++ util-linux-ng/configure.ac2008-01-07 21:40:50.0 +0100
> @@ -91,6 +92,11 @@ fi
> UTIL_CHECK_LIB(util, openpty)
> UTIL_CHECK_LIB(termcap, tgetnum)
>
>
Hello.
Indan Zupancic wrote:
> > I want to use this filesystem in case where a process with root privilege
> > was
> > hijacked but the behavior of the hijacked process is still restricted by
> > MAC.
>
> 1) If the behaviour can be controlled, why can't the process be
>disallowed to change
Hello.
[EMAIL PROTECTED] wrote:
> Ouch. The .c files should generally be built into their own .o files and
> then the Makefile should do something like
>
> obj-$(CONFIG_SYAORAN) += syaoran.o
>
> unless there's *really* good reasons for including .c files (such as an
> otherwise-messy variable-n
After much sitting in -mm, Andrew dropped this patchset due to
conflicts with other stuff. It would be nice, if it could be reviewed
in time for 2.6.26 (2.6.25 is closed as far as I understand).
v5 -> v6:
- update to latest -mm
- preliminary util-linux-ng support (will post right after this se
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
From: Miklos Szeredi <[EMAIL PROTECTED]>
On mount propagation, let the owner of the clone be inherited from the
parent into which it has been propagated. Also if the parent has the
"nosuid" flag, set this flag for the child as well.
This makes sense for example, when propagation is set up from t
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
- parent mount is owned by the user
- the number of user mounts is below the maximum
Unprivileged mounts imply MS_SETUSER, and will also have
From: Miklos Szeredi <[EMAIL PROTECTED]>
This patchset adds support for keeping mount ownership information in the
kernel, and allow unprivileged mount(2) and umount(2) in certain cases.
The mount owner has the following privileges:
- unmount the owned mount
- create a submount under the own
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
[akpm]
- don't use en
From: Miklos Szeredi <[EMAIL PROTECTED]>
This is an experimental patch for supporing unprivileged mounts and
umounts. The following features are added:
1) If mount/umount are suid, first try without privileges.
This is done by forking, dropping privileges in child, and redirecting
stderr to /de
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 a new mount flag "nomnt", which denies submounts for the owner.
This would be useful, if we want to support traditional /etc/fstab
based user mounts.
In this case mount(8) would still have to be suid-root, to check the
mountpoint against the user/users
37 matches
Mail list logo
