Project

General

Profile

Actions

Bug #47

closed

nullfs mount ignores readonly flag

Added by dbeck almost 16 years ago. Updated about 15 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

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.

Actions #1

Updated by dbeck almost 16 years ago

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
<>

: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.

Actions #2

Updated by corecode almost 16 years ago

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

Actions #3

Updated by dbeck almost 16 years ago

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

Actions #4

Updated by check+isu2oi00rsa902br almost 16 years ago

David Beck <> 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

Actions #5

Updated by corecode about 15 years ago

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

Actions #6

Updated by dbeck about 15 years ago

Hello,

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

Regards, David.

Actions

Also available in: Atom PDF