Bug#688412: Debian-init-diversity Digest, Vol 3, Issue 63

[Roger Leigh]

On 29/12/2018 18:36, 
debian-init-diversity-request at chiark.greenend.org.uk wrote:
>> The result was:
>> domount: mount tmpfs shmfs /tmp tmpfs -onodev,nosuid,size=512m,mode=1777
>>
>> So configuration options are recognized by the initialization scripts and
>> passed to the "mount" utility, but somehow get lost later. There are similar
>> /etc/fstab records for other tmpfs mounts (/run, /run/lock and /run/shm) but
>> only /tmp doesn't work as expected.
> Confirmed. I do not see bug at glance, but I will definitely take a
> closer look. Sorry for very late reply.

Might be worth checking if this is being overridden by anything in 
/etc/default/tmpfs.  The above output should account for that, though. 
  If an fstab entry is present, then this should always take priority 
over the default/tmpfs variables, by design.In mount-functions:

         if read_fstab_entry /tmp; then
             if [ "$MNT_TYPE" = "tmpfs" ] ; then
                 RAMTMP="yes"
             else
                 RAMTMP="no"
             fi
         fi

The else case might need to set TMP_OPT="" so that when an fstab entry 
exists the options can't be overridden.  Looks like we only avoid 
overriding mounting or not, not the default options.

This applies to all of the various tmpfs mount functions (run, lock, 
shm, tmp).


Regards,
Roger