DragonFlyBSD

Would that fix mean that the no-setuid, no-exec and other flags will
work as well?

Regards, David.

Matthew Dillon wrote:

I expect there will be things that need working on. That's one of
them. Hmm. We will probably have to hold the namecache entry for
normal files and use the namecache's mount point to check for the
read-only filesystem status. No biggy (we already do this for
directories to maintain the CD path), but it may take a few days to
fix.

-Matt
Matthew Dillon
<dillon@backplane.com>

:Hello,
:
:A few experiments on 1.5 nullfs showed that it ignores the read-only flag:
:
:/mnt: mkdir 1 2
:/mnt: mount_null -o ro /mnt/1 /mnt/2
:/mnt: mount
:..
:/mnt/1 on /mnt/2 (null, local, read-only)
:/mnt: cd /mnt/1
:/mnt/1: echo > k
:/mnt/1: cd /mnt/2
:/mnt/2: rm k
:/mnt/2: ls
:/mnt/2: cd /mnt/1
:/mnt/1: ls -ltr
:total 0
:/mnt/1:
:
:
:I could delete a file on a read-only filesystem. Oops.
:
:Regards, David.

David Beck wrote:

Would that fix mean that the no-setuid, no-exec and other flags will
work as well?

Regards, David.

Matthew Dillon wrote:

I expect there will be things that need working on. That's one of
them. Hmm. We will probably have to hold the namecache entry for
normal files and use the namecache's mount point to check for the
read-only filesystem status. No biggy (we already do this for
directories to maintain the CD path), but it may take a few days to
fix.

Talking of nullfs: I'd strongly advise not to use it in its current
state in production. There are many things that need to be resolved
first. See my post on kernel@

cheers
simon

OK. Thanks for the advise.

[I know this should go to another newsgroup...]

The idea was to use nullfs for jail filesystems, so I don't need to
duplicate files as many times as jails I have.

This had two advantages to my opinion:
- the jail would share system executables on a readonly filesystem,
so system upgardes would be easier.
- also I thought that this would increase the level of security in
jails.

If not nullfs would you recommend NFS in a similar setup? Do you see an
other solution that works better?

Thank you very much,

David.

Simon 'corecode' Schubert wrote:

David Beck wrote:

Would that fix mean that the no-setuid, no-exec and other flags will
work as well?

Regards, David.

Matthew Dillon wrote:

I expect there will be things that need working on. That's one of
them. Hmm. We will probably have to hold the namecache entry for
normal files and use the namecache's mount point to check for the
read-only filesystem status. No biggy (we already do this for
directories to maintain the CD path), but it may take a few days to
fix.

Talking of nullfs: I'd strongly advise not to use it in its current
state in production. There are many things that need to be resolved
first. See my post on kernel@

cheers
simon

David Beck <dbeck@beckground.hu> wrote:
> The idea was to use nullfs for jail filesystems, so I don't need to
> duplicate files as many times as jails I have.
>
> This had two advantages to my opinion:
> - the jail would share system executables on a readonly filesystem,
> so system upgardes would be easier.
> - also I thought that this would increase the level of security in
> jails.
>
> If not nullfs would you recommend NFS in a similar setup? Do you see an
> other solution that works better?

Personally, I use NFS loopback union mounts (read-only) for
the very same thing (i.e. multiple jails). Note that, by
saying "union mounts" I mean the o union flag of the mount
command, not UNIONFS which I'd rather avoid. The -o union
flag serves a similar purpose and is rock stable. It's a
bit less flexible than UNIONFS because it merges only the
contents of the root directory of the file system mounted,
but that's usually sufficient (with the help of a few sym
links).

The performance of loopback NFS is very good. I was afraid
that the NFS overhead would kill the machine, but it turned
out not to be an issue.

Best regards
Oliver

I think this was fixed recently, can you test on -DEVEL?

Hello,

Sorry to say, I have abandoned Dragonfly and didn't keep the test
environment.

Regards, David.