https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082006-01-09T17:20:30ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #47: nullfs mount ignores readonly flaghttps://bugs.dragonflybsd.org/issues/47?journal_id=1602006-01-09T17:20:30Zdbeck
<ul></ul><p>Would that fix mean that the no-setuid, no-exec and other flags will <br />work as well?</p>
<p>Regards, David.</p>
<p>Matthew Dillon wrote:</p>
<blockquote>
<p>I expect there will be things that need working on. That's one of<br />them. Hmm. We will probably have to hold the namecache entry for<br />normal files and use the namecache's mount point to check for the<br />read-only filesystem status. No biggy (we already do this for <br />directories to maintain the CD path), but it may take a few days to<br />fix.</p>
<p>-Matt<br />Matthew Dillon <br /><<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>></p>
<p>:Hello,<br />:<br />:A few experiments on 1.5 nullfs showed that it ignores the read-only flag:<br />:<br />:/mnt: mkdir 1 2<br />:/mnt: mount_null -o ro /mnt/1 /mnt/2<br />:/mnt: mount<br />:..<br />:/mnt/1 on /mnt/2 (null, local, read-only)<br />:/mnt: cd /mnt/1<br />:/mnt/1: echo > k<br />:/mnt/1: cd /mnt/2<br />:/mnt/2: rm k<br />:/mnt/2: ls<br />:/mnt/2: cd /mnt/1<br />:/mnt/1: ls -ltr<br />:total 0<br />:/mnt/1:<br />:<br />:<br />:I could delete a file on a read-only filesystem. Oops.<br />:<br />:Regards, David.</p>
</blockquote> DragonFlyBSD - Bug #47: nullfs mount ignores readonly flaghttps://bugs.dragonflybsd.org/issues/47?journal_id=1662006-01-09T23:23:20Zcorecode
<ul></ul><p>David Beck wrote:</p>
<blockquote>
<p>Would that fix mean that the no-setuid, no-exec and other flags will <br />work as well?</p>
<p>Regards, David.</p>
<p>Matthew Dillon wrote:</p>
<blockquote>
<p>I expect there will be things that need working on. That's one of<br />them. Hmm. We will probably have to hold the namecache entry for<br />normal files and use the namecache's mount point to check for the<br />read-only filesystem status. No biggy (we already do this for <br />directories to maintain the CD path), but it may take a few days to<br />fix.</p>
</blockquote></blockquote>
<p>Talking of nullfs: I'd strongly advise not to use it in its current <br />state in production. There are many things that need to be resolved <br />first. See my post on kernel@</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #47: nullfs mount ignores readonly flaghttps://bugs.dragonflybsd.org/issues/47?journal_id=1672006-01-09T23:35:10Zdbeck
<ul></ul><p>OK. Thanks for the advise.</p>
<p>[I know this should go to another newsgroup...]</p>
<p>The idea was to use nullfs for jail filesystems, so I don't need to <br />duplicate files as many times as jails I have.</p>
<p>This had two advantages to my opinion:<br /> - the jail would share system executables on a readonly filesystem, <br />so system upgardes would be easier.<br /> - also I thought that this would increase the level of security in <br />jails.</p>
<p>If not nullfs would you recommend NFS in a similar setup? Do you see an <br />other solution that works better?</p>
<p>Thank you very much,</p>
<pre><code>David.</code></pre>
<p>Simon 'corecode' Schubert wrote:</p>
<blockquote>
<p>David Beck wrote:</p>
<blockquote>
<p>Would that fix mean that the no-setuid, no-exec and other flags will <br />work as well?</p>
<p>Regards, David.</p>
<p>Matthew Dillon wrote:</p>
<blockquote>
<p>I expect there will be things that need working on. That's one of<br />them. Hmm. We will probably have to hold the namecache entry for<br />normal files and use the namecache's mount point to check for the<br />read-only filesystem status. No biggy (we already do this for <br />directories to maintain the CD path), but it may take a few days to<br />fix.</p>
</blockquote>
</blockquote>
<p>Talking of nullfs: I'd strongly advise not to use it in its current <br />state in production. There are many things that need to be resolved <br />first. See my post on kernel@</p>
<p>cheers<br />simon</p>
</blockquote> DragonFlyBSD - Bug #47: nullfs mount ignores readonly flaghttps://bugs.dragonflybsd.org/issues/47?journal_id=1702006-01-10T01:10:10Zcheck+isu2oi00rsa902br
<ul></ul><p>David Beck <<a class="email" href="mailto:dbeck@beckground.hu">dbeck@beckground.hu</a>> wrote:<br /> > The idea was to use nullfs for jail filesystems, so I don't need to <br /> > duplicate files as many times as jails I have.<br /> > <br /> > This had two advantages to my opinion:<br /> > - the jail would share system executables on a readonly filesystem, <br /> > so system upgardes would be easier.<br /> > - also I thought that this would increase the level of security in <br /> > jails.<br /> > <br /> > If not nullfs would you recommend NFS in a similar setup? Do you see an <br /> > other solution that works better?</p>
<p>Personally, I use NFS loopback union mounts (read-only) for<br />the very same thing (i.e. multiple jails). Note that, by<br />saying "union mounts" I mean the <del>o union flag of the mount<br />command, <strong>not</strong> UNIONFS which I'd rather avoid. The -o union<br />flag serves a similar purpose and is rock stable. It's a<br />bit less flexible than UNIONFS because it merges only the<br />contents of the root directory of the file system mounted,<br />but that's usually sufficient (with the help of a few sym</del><br />links).</p>
<p>The performance of loopback NFS is very good. I was afraid<br />that the NFS overhead would kill the machine, but it turned<br />out not to be an issue.</p>
<p>Best regards<br /> Oliver</p> DragonFlyBSD - Bug #47: nullfs mount ignores readonly flaghttps://bugs.dragonflybsd.org/issues/47?journal_id=13722006-10-02T20:34:02Zcorecode
<ul></ul><p>I think this was fixed recently, can you test on -DEVEL?</p> DragonFlyBSD - Bug #47: nullfs mount ignores readonly flaghttps://bugs.dragonflybsd.org/issues/47?journal_id=13942006-10-03T04:16:00Zdbeck
<ul></ul><p>Hello,</p>
<p>Sorry to say, I have abandoned Dragonfly and didn't keep the test<br />environment.</p>
<p>Regards, David.</p>