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.