On Fri, 2007-04-13 at 13:58 +0200, Miklos Szeredi wrote:
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
1. clone the master namespace.
2. in the new namespace
move the tree under /share/$me to /
for each ($user, $what, $how) {
On Fri, 2007-04-13 at 16:05 +0200, Miklos Szeredi wrote:
Thinking a bit more about this, I'm quite sure most users wouldn't
even want private namespaces. It would be enough to
chroot /share/$USER
and be done with it.
Private namespaces are only good for keeping a
Arn't there ways to escape chroot jails? Serge had pointed me to a URL
which showed chroots can be escaped. And if that is true than having all
user's private mount tree in the same namespace can be a security issue?
No. In fact chrooting the user into /share/$USER will actually
_grant_ a
Miklos Szeredi [EMAIL PROTECTED] writes:
Arn't there ways to escape chroot jails? Serge had pointed me to a URL
which showed chroots can be escaped. And if that is true than having all
user's private mount tree in the same namespace can be a security issue?
No. In fact chrooting the user
Arn't there ways to escape chroot jails? Serge had pointed me to a URL
which showed chroots can be escaped. And if that is true than having all
user's private mount tree in the same namespace can be a security issue?
No. In fact chrooting the user into /share/$USER will actually
Thinking a bit more about this, I'm quite sure most users wouldn't
even want private namespaces. It would be enough to
chroot /share/$USER
and be done with it.
I don't think so. How to you want to implement non-shared /tmp
directories?
mount --bind /.tmp/$USER
Agreed on desired behavior, but not on chroot sufficing. It actually
sounds like you want exactly what was outlined in the OLS paper.
Users still need to be in a different mounts namespace from the admin
user so long as we consider the deluser and backup problems
I don't
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
1. clone the master namespace.
2. in the new namespace
move the tree under /share/$me to /
for each ($user, $what, $how) {
move /share/$user/$what to /$what
if ($how == slave) {
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
1. clone the master namespace.
2. in the new namespace
move the tree under /share/$me to /
for each ($user, $what, $how) {
move
Thinking a bit more about this, I'm quite sure most users wouldn't
even want private namespaces. It would be enough to
chroot /share/$USER
and be done with it.
Private namespaces are only good for keeping a bunch of mounts
referenced by a group of processes. But my guess
On Fri, Apr 13, 2007 at 01:58:59PM +0200, Miklos Szeredi wrote:
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
1. clone the master namespace.
2. in the new namespace
move the tree under /share/$me to /
for each ($user, $what, $how) {
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Thinking a bit more about this, I'm quite sure most users wouldn't
even want private namespaces. It would be enough to
chroot /share/$USER
and be done with it.
Private namespaces are only good for keeping a bunch of mounts
This patchset adds support for keeping mount ownership information in
the kernel, and allow unprivileged mount(2) and umount(2) in certain
cases.
Well, I'd like to feel all smart and point out some bugs, but the code
all reads very nicely, seems to work as advertised, and while I won't
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security
implication of allowing anyone to do bind mounts are poorly understood.
And especially so since there is no way for a filesystem
On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security
implication of allowing anyone to do bind mounts are poorly
Quoting Ian Kent ([EMAIL PROTECTED]):
On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security
implication of allowing
On Wed, 2007-04-11 at 09:26 -0500, Serge E. Hallyn wrote:
Quoting Ian Kent ([EMAIL PROTECTED]):
On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest
Quoting Ian Kent ([EMAIL PROTECTED]):
On Wed, 2007-04-11 at 09:26 -0500, Serge E. Hallyn wrote:
Quoting Ian Kent ([EMAIL PROTECTED]):
On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
- users can use bind mounts without having to pre-configure them
in
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
1. clone the master namespace.
2. in the new namespace
move the tree under /share/$me to /
for each ($user, $what, $how) {
move /share/$user/$what to /$what
if ($how == slave) {
It would be nice in general if we could avoid any sort of checks for
(mnt-mnt_ns == init_nsproxy.mnt_ns). Maybe that won't be possible,
but, taking the two listed examples:
[snip]
It's probably worthwile going after these problematic cases, and
fixing them, OTOH it's not easy to audit a
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
It would be nice in general if we could avoid any sort of checks for
(mnt-mnt_ns == init_nsproxy.mnt_ns). Maybe that won't be possible,
but, taking the two listed examples:
[snip]
It's probably worthwile going after these problematic cases,
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Not objecting to prctl(), but two other options would be
1. add a CLONE_NEW_NS_USERMNT flag - kind of ugly, but that is
the time at which the ns is created, so in that sense it
makes sense.
Yes, I thought about this, but
On Mon, 2007-04-09 at 22:10 +0200, Miklos Szeredi wrote:
The one in pam-0.99.6.3-29.1 in opensuse-10.2 is totally broken. Are
you interested in the details? I can reproduce it, but forgot to note
down the details of the brokenness.
I don't know how far removed that is from the one
On Fri, 2007-04-06 at 16:16 -0700, H. Peter Anvin wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security
implication of allowing anyone to do bind mounts are poorly understood.
And
On Mon, Apr 09, 2007 at 10:46:25AM -0700, Ram Pai wrote:
On Mon, 2007-04-09 at 12:07 -0500, Serge E. Hallyn wrote:
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
- need to set up mount propagation from global namespace to private
ones, mount(8) does not yet have options to configure
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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
On Mon, 2007-04-09 at 12:07 -0500, Serge E. Hallyn wrote:
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
- need to set up mount propagation from global namespace to private
ones, mount(8) does not yet have options to configure propagation
Hmm, I guess I get lost using my own little
Ram Pai wrote:
It is in FC6. I dont know the status off upstream util-linux. I did
submit the patch many times to Adrian Bunk (the then util-linux
maintainer) and got no response. I have not pushed the patches to the
new maintainer(Karel Zak?) though.
Well, do that, then :)
Seriously. The
The one in pam-0.99.6.3-29.1 in opensuse-10.2 is totally broken. Are
you interested in the details? I can reproduce it, but forgot to note
down the details of the brokenness.
I don't know how far removed that is from the one being used by redhat,
but assuming it's the same, then
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
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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
Quoting 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.
Well, I'd like to feel all smart and point out some bugs, but the code
all reads very nicely, seems to
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?
All we need is a comment from Andrew, and the replies come flooding in ;)
My knowledge of the code which you're touching is
On 4/6/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Jan Engelhardt wrote:
On Apr 6 2007 16:16, H. Peter Anvin wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security
implication of
On Wed, 04 Apr 2007 20:30:12 +0200 Miklos Szeredi [EMAIL PROTECTED] 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
On Apr 6 2007 16:16, H. Peter Anvin wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security implication of
allowing anyone to do bind mounts are poorly understood.
$ whoami
miklos
$ mount
Jan Engelhardt wrote:
On Apr 6 2007 16:16, H. Peter Anvin wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security implication of
allowing anyone to do bind mounts are poorly understood.
$ whoami
On 4/6/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Jan Engelhardt wrote:
On Apr 6 2007 16:16, H. Peter Anvin wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security implication
of
allowing anyone
This patchset adds support for keeping mount ownership information in
the kernel, and allow unprivileged mount(2) and umount(2) in certain
cases.
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
40 matches
Mail list logo