Clarification about mfs/tmpfs on /tmp

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Clarification about mfs/tmpfs on /tmp

r.gr
Dear OpenBSD Community,

I have been playing around with OpenBSD for ~2 weeks now, and I find
myself very much at home in a system that puts correctness and careful
development first. Needless to say that I have already made my first
donation; I sincerely thank the developers for their time and effort.

I plan to commit fully to OpenBSD on my laptop as soon as 6.4 stable
is out, but before doing so, I have one remaining question:

I would like to have either an mfs or tmpfs instance mounted at /tmp.
I have already managed this by using an appropriate entry in fstab,
but I have noticed, that the system also works, if fstab contains NO
entry for /tmp.

The first part of is: What is the default behavior in this case? Is an
instance of mfs/tmpfs mounted with default parameters?

The second part to my question is: What is the key difference between
mfs and tmpfs? Should I prefer one over the other?

The last part of my question concerns caching chromium data in /tmp.
I have read that the OpenBSD chromium port has been "pledged" and
"unveiled". Does this have any influence over whether I can run
chrome --disk-cache/dir=/tmp/chrome?

Thank you for taking the time to read my question.

Kind regards,
R.
Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

Solene Rapenne
<[hidden email]> wrote:

> Dear OpenBSD Community,
>
> I have been playing around with OpenBSD for ~2 weeks now, and I find
> myself very much at home in a system that puts correctness and careful
> development first. Needless to say that I have already made my first
> donation; I sincerely thank the developers for their time and effort.
>
> I plan to commit fully to OpenBSD on my laptop as soon as 6.4 stable
> is out, but before doing so, I have one remaining question:
>
> I would like to have either an mfs or tmpfs instance mounted at /tmp.
> I have already managed this by using an appropriate entry in fstab,
> but I have noticed, that the system also works, if fstab contains NO
> entry for /tmp.
>
> The first part of is: What is the default behavior in this case? Is an
> instance of mfs/tmpfs mounted with default parameters?
>
> The second part to my question is: What is the key difference between
> mfs and tmpfs? Should I prefer one over the other?
>
> The last part of my question concerns caching chromium data in /tmp.
> I have read that the OpenBSD chromium port has been "pledged" and
> "unveiled". Does this have any influence over whether I can run
> chrome --disk-cache/dir=/tmp/chrome?
>
> Thank you for taking the time to read my question.
>
> Kind regards,
> R.

hello,

if you don't put any /tmp in fstab, /tmp comes from the / partition, which
doesn't have nodev and nosuid mount options, and which is very tiny.

tmpfs has been disabled: see
https://marc.info/?l=openbsd-tech&m=148173068424515&w=2

main difference between mfs and tmpfs. mfs is a ffs mounted from memory and
will use the memory reserved for it, while tmpfs will use memory only when it's
really used. If you give 500 MB to mfs, it will be instantly used in your
memory, even if you have 0 file in it.

I don't know for chromium.

Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

Gregor Best

Hi,

>> [...]
>> The last part of my question concerns caching chromium data in /tmp.
>> I have read that the OpenBSD chromium port has been "pledged" and
>> "unveiled". Does this have any influence over whether I can run
>> chrome --disk-cache/dir=/tmp/chrome?
>> [...]

I don't know about the specifics of telling chrome to cache in
/tmp/chrome, but FWIW, I have a 2G MFS mounted to ~/.cache. It seems to
work fine that way.

> [...]
> main difference between mfs and tmpfs. mfs is a ffs mounted from memory and
> will use the memory reserved for it, while tmpfs will use memory only when it's
> really used. If you give 500 MB to mfs, it will be instantly used in your
> memory, even if you have 0 file in it.
> [...]

Small correction, the mount_mfs process that backs the MFS file system
has 500MB allocated, but the pages are not immediately used. You can see
that in top (use `g` to filter for `mount_mfs`). The processes have SIZE
corrosponding to the specified file system size and RES corrosponding to
the amount of space that was actually touched by FS operations.

Solene's right though in that space once used on an MFS is only released
when the MFS is unmounted.

>
> I don't know for chromium.
>

--
        Gregor

Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

r.gr
In reply to this post by Solene Rapenne
Solene Rapenne wrote:
> hello,

> if you don't put any /tmp in fstab, /tmp comes from the / partition, which
> doesn't have nodev and nosuid mount options, and which is very tiny.

> tmpfs has been disabled: see
> https://marc.info/?l=openbsd-tech&m=148173068424515&w=2 <https://marc.info/?l=openbsd-tech&m=148173068424515&w=2>

> main difference between mfs and tmpfs. mfs is a ffs mounted from memory and
> will use the memory reserved for it, while tmpfs will use memory only when it's
> really used. If you give 500 MB to mfs, it will be instantly used in your
> memory, even if you have 0 file in it.

> I don't know for chromium.

Thank you for your reply, this resolves my first two problems.
I have two follow-up questions:

1) Regarding mfs, using an fstab entry as in the example in fstab(5), i.e.,
    swap /tmp mfs rw,nodev,nosuid,-s=153600 0 0, gives me a /tmp with write
    permissions for root only (as opposed to mounting UID.d, where every
    user can write on /tmp). Looking up newfs(8), I don't see a way to set
    permissions, hence I have done this using a chmod command in rc.local.
    Is there a better way to set the right permissions for a mfs /tmp?

2) "tmpfs has been disabled": Would it make sense to write to the developer
    mailing list and suggest to either drop it (as I understand it, OpenBSD
    has a policy of dropping unsupported/unmaintained features) or at least
    to mention that tmpfs has been disabled in mount_tmpfs(8)?

Regards,
R
Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

Stuart Henderson
On 2018-10-09, <[hidden email]> <[hidden email]> wrote:

> Solene Rapenne wrote:
>> hello,
>
>> if you don't put any /tmp in fstab, /tmp comes from the / partition, which
>> doesn't have nodev and nosuid mount options, and which is very tiny.
>
>> tmpfs has been disabled: see
>> https://marc.info/?l=openbsd-tech&m=148173068424515&w=2 <https://marc.info/?l=openbsd-tech&m=148173068424515&w=2>
>
>> main difference between mfs and tmpfs. mfs is a ffs mounted from memory and
>> will use the memory reserved for it, while tmpfs will use memory only when it's
>> really used. If you give 500 MB to mfs, it will be instantly used in your
>> memory, even if you have 0 file in it.
>
>> I don't know for chromium.
>
> Thank you for your reply, this resolves my first two problems.
> I have two follow-up questions:
>
> 1) Regarding mfs, using an fstab entry as in the example in fstab(5), i.e.,
>     swap /tmp mfs rw,nodev,nosuid,-s=153600 0 0, gives me a /tmp with write
>     permissions for root only (as opposed to mounting UID.d, where every
>     user can write on /tmp). Looking up newfs(8), I don't see a way to set
>     permissions, hence I have done this using a chmod command in rc.local.
>     Is there a better way to set the right permissions for a mfs /tmp?

This one is easy, simply set the appropriate permissions on the
directory where you mount the mfs.




> 2) "tmpfs has been disabled": Would it make sense to write to the developer
>     mailing list and suggest to either drop it (as I understand it, OpenBSD
>     has a policy of dropping unsupported/unmaintained features) or at least

It's not included in the GENERIC kernel configuration but isn't
otherwise disabled. Actually removing code from the tree would make
it harder if anyone wants to fix it ..

>     to mention that tmpfs has been disabled in mount_tmpfs(8)?

Perhaps. Though I think in general with the mount_* manuals it's
assumed that the relevant support is compiled into the kernel for them
to work ..


Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

Martijn van Duren-6
On 10/9/18 2:03 PM, Stuart Henderson wrote:

> On 2018-10-09, <[hidden email]> <[hidden email]> wrote:
>> Solene Rapenne wrote:
>>> hello,
>>
>>> if you don't put any /tmp in fstab, /tmp comes from the / partition, which
>>> doesn't have nodev and nosuid mount options, and which is very tiny.
>>
>>> tmpfs has been disabled: see
>>> https://marc.info/?l=openbsd-tech&m=148173068424515&w=2 <https://marc.info/?l=openbsd-tech&m=148173068424515&w=2>
>>
>>> main difference between mfs and tmpfs. mfs is a ffs mounted from memory and
>>> will use the memory reserved for it, while tmpfs will use memory only when it's
>>> really used. If you give 500 MB to mfs, it will be instantly used in your
>>> memory, even if you have 0 file in it.
>>
>>> I don't know for chromium.
>>
>> Thank you for your reply, this resolves my first two problems.
>> I have two follow-up questions:
>>
>> 1) Regarding mfs, using an fstab entry as in the example in fstab(5), i.e.,
>>     swap /tmp mfs rw,nodev,nosuid,-s=153600 0 0, gives me a /tmp with write
>>     permissions for root only (as opposed to mounting UID.d, where every
>>     user can write on /tmp). Looking up newfs(8), I don't see a way to set
>>     permissions, hence I have done this using a chmod command in rc.local.
>>     Is there a better way to set the right permissions for a mfs /tmp?
>
> This one is easy, simply set the appropriate permissions on the
> directory where you mount the mfs.
>
>
>
>
>> 2) "tmpfs has been disabled": Would it make sense to write to the developer
>>     mailing list and suggest to either drop it (as I understand it, OpenBSD
>>     has a policy of dropping unsupported/unmaintained features) or at least
>
> It's not included in the GENERIC kernel configuration but isn't
> otherwise disabled. Actually removing code from the tree would make
> it harder if anyone wants to fix it ..
>
>>     to mention that tmpfs has been disabled in mount_tmpfs(8)?
>
> Perhaps. Though I think in general with the mount_* manuals it's
> assumed that the relevant support is compiled into the kernel for them
> to work ..
>
>
So what about unlinking the tool from the build?
Probably not until after release though.

This probably should probably be done in the rd as well, but I'm not
familiar enough with that part of the tree to include it in this
quick diff.

martijn@

Index: Makefile
===================================================================
RCS file: /cvs/src/sbin/Makefile,v
retrieving revision 1.106
diff -u -p -r1.106 Makefile
--- Makefile 3 Jun 2017 10:00:29 -0000 1.106
+++ Makefile 9 Oct 2018 12:13:30 -0000
@@ -4,7 +4,7 @@ SUBDIR= atactl badsect bioctl clri dhcli
  disklabel dmesg dump dumpfs fdisk fsck fsck_ext2fs fsck_ffs  \
  fsck_msdos fsdb fsirand growfs ifconfig iked init ipsecctl  \
  isakmpd kbd ldattach mknod mount \
- mount_cd9660 mount_ext2fs mount_ffs mount_msdos \
+ mount_cd9660 mount_ffs mount_msdos \
  mount_nfs mount_ntfs mount_tmpfs mount_udf \
  mount_vnd mountd ncheck_ffs newfs newfs_ext2fs newfs_msdos \
  nfsd nologin pdisk pfctl pflogd ping quotacheck \

Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

r.gr
In reply to this post by Stuart Henderson
This is a reply to both Stuart Henderson and Gregor Best.

> This one is easy, simply set the appropriate permissions on the
> directory where you mount the mfs.

Will do.

> [...] it's assumed that the relevant support is compiled into the
> kernel [...]

I understand. Than it would be a matter of mentioning for "every" man
page whether the respective feature is supported by the GENERIC kernel.
Since this can be investigated when in doubt (or asking the mailing
list), it's not necessary to include this information in the man pages.

> I don't know about the specifics of telling chrome to cache in
> /tmp/chrome, but FWIW, I have a 2G MFS mounted to ~/.cache. It seems to
> work fine that way.

Good idea. If it doesn't work with /tmp, I'll try it this way.

Thank you both for the valuable answers.
Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

Felix Maschek
In reply to this post by r.gr
On 10/8/18 11:27 PM, [hidden email] wrote:
> chrome --disk-cache/dir=/tmp/chrome?

This works fine for me.

BTW, I've set up a RAM based /tmp directory using the following
/etc/fstab entry:

     #/dev/sd0f /tmp ffs rw,nodev,nosuid 1 2
     swap /tmp mfs rw,noexec,nodev,nosuid,-s=512m 0 0

But I had to call

     doas umount -f /tmp        # no running X-server

and

     doas chmod 777 /tmp

:x Felix

Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

r.gr
I recall having to do this as well (in fact, as mentioned earlier
in this thread):

> doas chmod 777 /tmp

If I understood Stuart Henderson correctly, then

> This one is easy, simply set the appropriate permissions
> on the directory where you mount the mfs.

implies that irrespective of what is mounted at /location,
the permissions are inherited from /location. But in the "mfs
at /tmp"scenario, this thesis is contradicted, as (e.g.)

 /dev/sd0f /tmp ffs rw,nodev,nosuid 1 2

will yield the desired 777 permissions on /tmp, whereas

 swap /tmp mfs rw,noexec,nodev,nosuid,-s=512m 0 0

will require manual adjustment via chmod.

So it appears that I have not quite understood this final part.
Would anyone be kind enough to elaborate on this?
What is the difference in inheriting permissions when mounting
an mfs instance vs. (e.g.) an ffs filesystem?
Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

Alexander Hall


On October 9, 2018 6:17:05 PM GMT+02:00, [hidden email] wrote:

>I recall having to do this as well (in fact, as mentioned earlier
>in this thread):
>
>> doas chmod 777 /tmp
>
>If I understood Stuart Henderson correctly, then
>
>> This one is easy, simply set the appropriate permissions
>> on the directory where you mount the mfs.
>
>implies that irrespective of what is mounted at /location,
>the permissions are inherited from /location. But in the "mfs
>at /tmp"scenario, this thesis is contradicted, as (e.g.)
>
> /dev/sd0f /tmp ffs rw,nodev,nosuid 1 2
>
>will yield the desired 777 permissions on /tmp, whereas
>
> swap /tmp mfs rw,noexec,nodev,nosuid,-s=512m 0 0
>
>will require manual adjustment via chmod.
>
>So it appears that I have not quite understood this final part.
>Would anyone be kind enough to elaborate on this?
>What is the difference in inheriting permissions when mounting
>an mfs instance vs. (e.g.) an ffs filesystem?

When you create and mount an mfs, its root node will "inherit" (or copy) the permissions of the mount point.

When you mount an ffs filesystem, it already has an existing root node from the time it was newfs'd, which will not be modified based on the underlying mount point.

On a sidenote, 777 is not the proper permissions for /tmp.

/Alexander

Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

r.gr
In reply to this post by r.gr
Alexander wrote:
> When you create and mount an mfs, its root node will "inherit" (or copy) the permissions of the mount point.

> When you mount an ffs filesystem, it already has an existing root node from the time it was newfs'd, which will not be modified based on the underlying mount point.

> On a sidenote, 777 is not the proper permissions for /tmp.

Thank you very much!
With this reply, I consider my questions resolved.

Kind regards,
R.
Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

Felix Maschek
In reply to this post by Alexander Hall

On 10/9/18 11:46 PM, Alexander Hall wrote:
> On a sidenote, 777 is not the proper permissions for /tmp.


What is the proper permission for /tmp?

~Felix

Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

Paul de Weerd
On Wed, Oct 10, 2018 at 10:20:32AM +0200, Felix Maschek wrote:
|
| On 10/9/18 11:46 PM, Alexander Hall wrote:
| > On a sidenote, 777 is not the proper permissions for /tmp.
|
|
| What is the proper permission for /tmp?

1777 (you need to enable the sticky bit on the directory, see
sticky(8) for more information)

Cheers,

Paul 'WEiRD' de Weerd

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

Eivind Eide-2
In reply to this post by r.gr
I was not able to get correct permissions on my mfs /tmp until I put
the following in /etc/rc.securelevel, which solved the problem.
/bin/chmod 1777 /tmp


--



Eivind Eide

"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
- Oceania Association of Autonomous Astronauts

Reply | Threaded
Open this post in threaded view
|

Re: Clarification about mfs/tmpfs on /tmp

Otto Moerbeek
On Wed, Oct 10, 2018 at 12:59:27PM +0200, Eivind Eide wrote:

> I was not able to get correct permissions on my mfs /tmp until I put
> the following in /etc/rc.securelevel, which solved the problem.
> /bin/chmod 1777 /tmp

That is not the right solution. The right one is to unmount /tmp (boot
to single user mode if needed), and then do a chmod 1777 /tmp. That
will make sure any mfs mounted filesystem on top of /tmp gets 1777 as
permissions.


        -Otto