On Wed, 28 Feb 2001, Alexander Viro wrote:
> > And disadvantages: you can't have broken symlinks.
> >
> > This actually turns out to be quite a bit of a problem when one tries
> > to use bind mounts with autofs. For one thing, it's perfectly legal
> > to have /autofs/foo as a symlink to /autofs/
On Wed, 28 Feb 2001, Ion Badulescu wrote:
> On Wed, 28 Feb 2001 13:07:29 -0500 (EST), Alexander Viro <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 28 Feb 2001, David L. Parsley wrote:
>
> >> Yeah, mount --bind is cool, I've been using it on one of my projects
> >> today. But - maybe I'm just not
On Wed, 28 Feb 2001 13:07:29 -0500 (EST), Alexander Viro <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Feb 2001, David L. Parsley wrote:
>> Yeah, mount --bind is cool, I've been using it on one of my projects
>> today. But - maybe I'm just not thinking creatively enough - what are
>> the advantages o
On Wed, 28 Feb 2001, David L. Parsley wrote:
> Alexander Viro wrote:
> > > Evil idea of the day: non-directory (even non-existant) mount points and
> > > non-directory mounts. So then "mount --bind /etc/foo /dev/bar" works.
> >
> > Try it. It _does_ work.
>
> Yeah, mount --bind is cool, I've
Alexander Viro wrote:
> > Evil idea of the day: non-directory (even non-existant) mount points and
> > non-directory mounts. So then "mount --bind /etc/foo /dev/bar" works.
>
> Try it. It _does_ work.
Yeah, mount --bind is cool, I've been using it on one of my projects
today. But - maybe I'm ju
On Wed, 28 Feb 2001, Albert D. Cahalan wrote:
> Alexander Viro writes:
>
> > * CLONE_NEWNS is made root-only (CAP_SYS_ADMIN, actually)
>
> Would an unprivileged version that killed setuid be OK to have?
>
> Evil idea of the day: non-directory (even non-existant) mount points and
> non-di
On Wed, 28 Feb 2001, Albert D. Cahalan wrote:
> Alexander Viro writes:
>
> > * CLONE_NEWNS is made root-only (CAP_SYS_ADMIN, actually)
>
> Would an unprivileged version that killed setuid be OK to have?
Not until we get decent resource accounting here.
> Evil idea of the day: non-direct
Alexander Viro writes:
> * CLONE_NEWNS is made root-only (CAP_SYS_ADMIN, actually)
Would an unprivileged version that killed setuid be OK to have?
Evil idea of the day: non-directory (even non-existant) mount points and
non-directory mounts. So then "mount --bind /etc/foo /dev/bar" works.
New version uploaded on ftp.math.psu.edu/pub/viro/namespaces-d-S2.gz
Changes:
* fixed an idiotic bug in get_filesystem_info() that din't
unfortunately) show up on UP.
* nosuid/nodev/noexec work in any combinations (had been b0rken in
previous version).
* fixed m
[EMAIL PROTECTED] said:
> > Have you thought about supporting .tar.gz into ramfs? Creating custom
> > boot images would be simpler.
> *uh*. It's definitely easier to do than it used to be, but I'm
> seriously sceptical about adding more cruft into the thing.
The really neat part of untarring in
On Mon, Feb 26, 2001 at 08:26:23AM -0800, Peter J. Braam wrote:
> - when you login, you get imounted into an environment where you have full
> priviliges (except mknod). The "/" of your environment is not a directory
> in the Unix tree.
> - in this environment the system file systems are availa
Hi Al,
Very neat!
Ron Minnich and I built something similar: we built private namespaces for
login sessions. Ours have slightly different semantics I think.
To do so we changed mount+chroot into "imount" (i = invisible). This landed
a process in a file system that had no root in the Unix dire
New version uploaded on ftp.math.psu.edu/pub/viro/namespaces-a-S2.gz
Changes:
* nosuid, nodev and noexec are per-mountpoint now.
* new flag for mount() - MS_MOVE (move a subtree, probable syntax
for mount(8) - mount --move old new; old must be a mountpoint)
* Fixes
On Mon, 26 Feb 2001, Marco d'Itri wrote:
> On Feb 26, Alexander Viro <[EMAIL PROTECTED]> wrote:
>
> >There is no way to implement them without credentials' cache. Which needs
> >to be done for many other reasons, but that's a separate patch and
> >separate story. If it's done - no serious p
On Feb 26, Alexander Viro <[EMAIL PROTECTED]> wrote:
>There is no way to implement them without credentials' cache. Which needs
>to be done for many other reasons, but that's a separate patch and
>separate story. If it's done - no serious penalty involved. However,
>I doubt that we want a uni
On Mon, 26 Feb 2001 [EMAIL PROTECTED] wrote:
> > BTW, we probably want to add mount --move - atomically moving
> > a subtree from one place to another. Code is there, we just need to
> > decide on API. Andries?
>
> Since we already have "mount --bind olddir newdir" this is not
> an unreasona
> BTW, we probably want to add mount --move - atomically moving
> a subtree from one place to another. Code is there, we just need to
> decide on API. Andries?
Since we already have "mount --bind olddir newdir" this is not
an unreasonable extension of the mount(8) syntax.
And since the kernel i
On Mon, 26 Feb 2001, Werner Almesberger wrote:
> Alexander Viro wrote:
> > No. Just an overmount.
>
> Ah, too bad. Union mounts would have been really elegant (allowing the
> operation to be repeated without residues, and also allowing umounting
> of the covered FS as a sanity check). But I gu
Alexander Viro wrote:
> No. Just an overmount.
Ah, too bad. Union mounts would have been really elegant (allowing the
operation to be repeated without residues, and also allowing umounting
of the covered FS as a sanity check). But I guess there's no way to
implement them without performance penal
On Sun, 25 Feb 2001, Werner Almesberger wrote:
> Alexander Viro wrote:
> > No kludges actually needed. "Simplified boot sequence" _is_ simplified -
> > we overmount the "final" root over ramfs. Initially empty. So you have
> > the normal environment when you load ramdisk, etc.
>
> So is this t
Alexander Viro wrote:
> No kludges actually needed. "Simplified boot sequence" _is_ simplified -
> we overmount the "final" root over ramfs. Initially empty. So you have
> the normal environment when you load ramdisk, etc.
So is this the Holy Grail, err, union mount we've discussed about one year
In article <[EMAIL PROTECTED]> you wrote:
> A better approach might be to find or invent a generic compressed file system.
> Given that, you just build a compressed root, copy an image of it into ramdisk
> and let the compressed FS driver handle it from there. I suspect such a driver
> might be u
On Sun, 25 Feb 2001, Sandy Harris wrote:
> One is just mount a ramdisk and extract a tarball into its root. Yes, this has
> some problems -- how do you load tar when you haven't set up your root? -- but
> I suspect they can be solved. At worst, this would involve some strictly limited
> kluge t
Alexander Viro wrote:
> > Have you thought about supporting .tar.gz into ramfs? Creating custom
> > boot images would be simpler.
>
> *uh*. It's definitely easier to do than it used to be, but I'm seriously
> sceptical about adding more cruft into the thing. ...
>
> (I presume that you mean "un
On Sun, 25 Feb 2001, Manfred Spraul wrote:
>
> > * large cleanup of boot process (ramdisk handling, etc.)
>
> Have you thought about supporting .tar.gz into ramfs? Creating custom
> boot images would be simpler.
*uh*. It's definitely easier to do than it used to be, but I'm seriously
scepti
On Sun, 25 Feb 2001, Rick Hohensee wrote:
[I wrote]
> >ask. So far that's the best I can do - all documentation is a pile of
> >notes
> >+ CVS log.
[snip]
> That sounds like an especially fascinating pile of notes. Perhaps you
> could pile it next to the patch on the ftp site?
You know, CDA
>I'm more than willing to answer questions on the design of the thing -
>just
>ask. So far that's the best I can do - all documentation is a pile of
>notes
>+ CVS log.
>
>Cheers,
>
27 matches
Mail list logo
