/tmp permission problem

Hi, I was wondering if you could give me how to figure out what was going on.

The problem is, the permission of '/tmp' directory got modified to '0700' after upgrading some packages.

Today, I have upgraded the following packages by 'opkg upgrade', and after that, the permission was changed to 0700. Before doing 'opkg upgrade', that was '1777'. That' for sure, I was checking the permission while I was upgrading.

upgraded packages were

  • freeradius3-common
  • freeradius3
  • freeradius3-mod-eap
  • freeradius3-mod-expr
  • freeradius3-mod-logintime
  • freeradius3-mod-radutmp
  • freeradius3-mod-attr-filter
  • freeradius3-mod-eap-tls
  • freeradius3-mod-preprocess
  • freeradius3-utils
  • freeradius3-mod-exec
  • freeradius3-mod-realm
  • dnsmasq-full

Actually, this was not the first time. I have been facing the same problem after I have upgrade to 19.07.2. When I was using 18.06, I have never faced such problem.

In addition, when I have booted my openwrt (19.07.2), the permission is always get '0700', so I have always needed to fix it to '1777'.

I have tried to figure out what caused this mess, but could not find out.
Can you please advice me how to find the root cause.

Many thanks in advnce.

--
eiji

You said you upgraded packages? Iā€™d recommend that you start over (reset to defaults).

opkg upgrade can result in major problems. It is generally highly discouraged, unless you know what you are doing or if there is specific instruction to do so.

2 Likes

@psherman

Thanks, I didn't know that. I thought it is really 'normal' to upgrade by 'opkg upgrade'.

Nevertheless, how can I understand the same problem after reboot. I have got this '/tmp permission' problem after reboot. Is there any way to fix it ?

--
eiji

I cannot explain why the permissions have changed, but as of now, I can only assume that it has something to with the opkg upgrade process. However, with history as my guide, many of these unexplained issues happen as a result of upgrading packages and the solution is simply to reset to defaults. In addition, any true bug or glitch becomes much harder to troubleshoot as a result of the unpredictable effects of the upgrades (you really don't want to chase your tail trying to solve an issue when there are contributing factors that are now outside your control and unknown to you and anyone trying to help).

If the problem still occurs after you have reset to defaults, that would be worth further investigating.

Check first that a tmpfs is being mounted at /tmp, because you could be destroying your device's flash memory.

What is the output of "mount"?

1 Like

@eduperez

Thanks, here is the result from "mount"

/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mtdblock8 on /overlay type jffs2 (rw,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)

I think this seems to be normal...

--
eiji

@psherman

I really appreciate your explanation. Yes, sometime it's hard to explain what was going on behind.

But, practically, how can I reset my settings of each package ?. I don't want to do factory reset. Is there any way to reset the package setting (but not openwrt itself) ? Sorry, I never do this before, so I don't know how to do that.

--
eiji

You could try to use opkg remove and even use the additional flags to force remove and force remove dependencies, but I think you might get yourself into an even more problematic situation. The problem is that there may have been various dependencies that were upgraded as part of the process... getting back to the known-good state is hard when you don't have any way to know what specifically broke things.

If you take a backup before you reset to defaults, you can simply restore the backup and be running with the same configuration again. You'll need to reinstall any additional packages that you had installed (don't upgrade any, though), but otherwise it can actually be fairly painless. I am reasonably confident that you will spend far more time and effort and experience more frustration trying to 'undo' the upgrades than you would by simply resetting.

@psherman

Now I know what you mean by 'reset '. That's possible. I can store current setting as backup and do factory reset (and install additional packages without doing 'upgrade') and restore my settings. That's not so difficult.

But my stomach is still not so clear, because this never happens in 18.06.
I really want to follow the latest stable tree so decided to upgrade from 18.06 to 19.07, but my personal impression is that 18.06 is much stable than 19.07. That is really sad.

--
eiji

See how things go with 19.07 once you have done the reset. I honestly think you just got lucky that the upgrade process never caused you pain with an earlier release. If you look through these forums, you will find examples of people who experienced problems after upgrading packages on 18.06.

I have personally found 19.07 to be rock solid.

1 Like

@psherman

Thanks, you maybe right. I was just lucky when I lived with 18.06.
I will follow your instruction and will see how things will be settled.

Many thanks.

--
eiji

I had a quick look at the Makefile for freeradius and found nothing related to /tmp and permissions.
So I had a quick look at the install script from freeradius and without looking in depth, there is the possibility of something happening with /tmp and permissions.

https://github.com/FreeRADIUS/freeradius-server/blob/master/install-sh (line 344)

This seems to run "mkdir -m700 -p -- /tmp/..." in some circumstances (which I'm not going to look into).
There is a chance that this could have something to do with the change on your system at install time. I'd say that's one where the package maintainer could have a look, maybe open a bug in packages if you can reproduce.

1 Like

@VincentR

Many thanks for your advice. I could not find this possibility only by myself.
really appreciate it.

But I still wonder why this problem happens after reboot. Maybe there might be some different problem behind.

I will try to reproduce the problem and if I can, I will raise a bug report.

Thank you for your kind advice.

--
eiji

@VincentR

I tried to reproduce the problem and still not 100% sure, but found some updates.

I have flashed 19.07.2 and did some configuration. Everything works fine, before I have installed freeradius3. I did NOT do opkg upgrade. I just did opkg update and opkg install something.

But after I have installed freeradius3, then my "/tmp" permission was changed to '0700'.

So I think this mess was not caused by 'opkg upgrade', but by freeradius3.

I would like to find out the root cause by myself, but don't know how to.
Maybe the 'install-sh' caused this mess, but how can I confirm this ?

--
eiji

I have found the root cause now, sorry it was my configuration problem but not freeradius3 package itself.

But nevertheless, I found some opportunity to avoid the same problem by adding one line in startup script. so would like to submit pull request.

According to FreeRADIUS document, if you want to use eap-tls, "/tmp/radiusd" has to be created before server starts.

https://networkradius.com/doc/3.0.10/raddb/tls/tls-config_verify.html

Syntax
tmpdir = string

Default
/tmp/radiusd

Description
A temporary directory where the client certificates are stored. This directory MUST be owned by the UID of the server and MUST not be accessible by any other users. When the server starts, it will do chmod go-rwx on the directory, for security reasons. The directory MUST exist when the server starts. All of the files in the directory should also be deleted when the server starts.

So I want to submit this small pull request, although I never did before.
I will try to find how to do this and try.

@psherman, @eduperez, @VincentR

Many thanks for your kind advice. Now my openwrt works pretty stable.

--
eiji

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.