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-next>] [day] [month] [year] [list]
Message-Id: <20070406160238.f3178189.akpm@linux-foundation.org>
Date:	Fri, 6 Apr 2007 16:02:38 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	linux-fsdevel@...r.kernel.org, util-linux-ng@...r.kernel.org,
	containers@...ts.osdl.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 0/8] unprivileged mount syscall

On Wed, 04 Apr 2007 20:30:12 +0200 Miklos Szeredi <miklos@...redi.hu> wrote:

> This patchset adds support for keeping mount ownership information in
> the kernel, and allow unprivileged mount(2) and umount(2) in certain
> cases.

No replies, huh?

My knowledge of the code which you're touching is not strong, and my spare
reviewing capacity is not high.  And this work does need close review by
people who are familar with the code which you're changing.

So could I suggest that you go for a dig through the git history, identify
some individuals who look like they know this code, then do a resend,
cc'ing those people?  Please also cc linux-kernel on that resend.

> This can be useful for the following reasons:
> 
> - mount(8) can store ownership ("user=XY" option) in the kernel
>   instead, or in addition to storing it in /etc/mtab.  For example if
>   private namespaces are used with mount propagations /etc/mtab
>   becomes unworkable, but using /proc/mounts works fine
> 
> - fuse won't need a special suid-root mount/umount utility.  Plain
>   umount(8) can easily be made to work with unprivileged fuse mounts
> 
> - users can use bind mounts without having to pre-configure them in
>   /etc/fstab
> 
> All this is done in a secure way, and unprivileged bind and fuse
> mounts are disabled by default and can be enabled through sysctl or
> /proc/sys.
> 
> One thing that is missing from this series is the ability to restrict
> user mounts to private namespaces.  The reason is that private
> namespaces have still not gained the momentum and support needed for
> painless user experience.  So such a feature would not yet get enough
> attention and testing.  However adding such an optional restriction
> can be done with minimal changes in the future, once private
> namespaces have matured.

I suspect the people who developed and maintain nsproxy would disagree ;)

Please also cc containers@...ts.osdl.org.

> An earlier version of these patches have been discussed here:
> 
>   http://lkml.org/lkml/2005/5/3/64
> 
> --
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ