permissions /var/tmp

[fraternl]

I've noticed that a sudo user I have on my Fritzbox isn't able to write to /var/tmp
Even though the script is started with sudo I still can't write to /var/tmp (which is normal)

Because of this the function mktemp doesn't work.
In the script I can invoke **mktemp --tmpdir=$HOME**, but I don't know into what I run next.
I also don't think it's that elegant. I don't want to create temporary files in the home folder for root if the script is run as root.
I prefer not having to think about these special cases when I write something in the future.

In the previous boxes the /var/tmp folder has a sticky bit set
drwxrwxrwt 7 root root 2180 Nov 6 10:31 tmp
Now it's this:
drwxr-xr-x 9 root root 3740 Nov 6 10:31 tmp
Who has set these permissions? AVM or Freetz-NG?

As I said, I already have several workarounds, but how unsafe is the old permission of /tmp with a sticky bit??

https://www.redhat.com/sysadmin/suid-sgid-sticky-bit

[fraternl]

As a workaround to writing to /tmp I chose this approach.
I do not want to change the permission of /tmp just yet.

TMP1=`mktemp` 2>/dev/null || TMP1=`mktemp --tmpdir=$HOME`
/sbin/ifconfig | egrep '^(wlan|wifi)' | awk '{print $1}' >${TMP1}

Maybe I'm overthinking it too much as this is giving me a working solution for this script.
I just don't like "special cases" and I don't want to have to think about not using /tmp directly when I write a script.
On the other hand I don't have that many scripts anyhow for this special user.

[fda77]

AVM changes the /tmp behaviour many times, eg set to 700 some FOS versions ago. If i remember correctly, ctlmgr unpacks /var.tar to /var/tmp (/tmp links to it). ctlmgr is a closed source blob and you never know what it really does
Some FOS versions ago it was usfficant for 1777 to : https://github.com/Freetz-NG/freetz-ng/blob/master/fwmod#L802
Later https://github.com/Freetz-NG/freetz-ng/blob/master/make/libs/libctlmgr/Config.in#L11 prevented avm's silly chmod but this is not used in all fos versions (i dont know yours)
So when something does not work again, addition fixes for common linux behavious are needed...

[fda77]

Old FOS without systemd-alike unpacked var in ./etc/init.d/rc.S, newer in build/original/filesystem/etc/boot.d/core/head.
But there is no sticky in build/*/filesystem/var.tar so it could no be unpacked... You could try to extend 68eaf28

In the previous boxes the /var/tmp folder has a sticky bit set

sure? You have to find what changed...

[fraternl]

I decided to be more careful when writing scripts for non-priviliged users. It may break things I don't know about and it's not worth that.
Better that it breaks things I have my hands on.

I'm sure however about the Freetz /tmp permission on boxes running 7.12 / 7.13 and older.

Thanks for your input

[fda77]

as libctlmgr is not longer used this could help, pleae test

• a8d0dcc

but its possible that avm meanwhile overwrites the permissions on other even then "reconnect"

But 755 as on my devices is a bad idea because only root users could use tmp

[fraternl]

Yes, the /tmp folder is now working for non-privileged users.
I'm keeping some of my workarounds, like creating a /home/user folder for the non-privileged user and the code where it will put the file there if mktemp is unsuccessful

[fda77]

Ive planned linctlmgr support for the current supervisor start of ctlmgr for the future (weeks up to months) to prevent again this permission changeds. But the workarounds should keep

[fraternl]

I already noticed on a box that permissions reverted or were not set:

stat /var/tmp
File: /var/tmp
Size: 3580 Blocks: 0 IO Block: 4096 directory
Device: dh/13d Inode: 1453 Links: 12
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-04-27 00:00:00.000000000 +0200
Modify: 2023-11-09 10:46:36.801741923 +0100
Change: 2023-11-09 10:46:36.801741923 +0100

reboot

stat /var/tmp
File: /var/tmp
Size: 3540 Blocks: 0 IO Block: 4096 directory
Device: dh/13d Inode: 1505 Links: 11
Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-04-27 00:00:00.000000000 +0200
Modify: 2023-11-09 10:53:40.429245850 +0100
Change: 2023-11-09 10:53:40.429245850 +0100

It was the first boot after flashing it. It may well be the reason why the /var/tmp was not set or reverted the setting.
I will report if I see a box which doesn't have /var/tmp with 1777 permissions (I have many).

I'm now monitoring the permission of /var/tmp and I will also be notified of a change in the permission. I have some 15 boxes that do not have 1777 applied (anymore?)

other box with problem:

root@# stat -c '%a' /var/tmp
755
root@# grep -C2 1777 /etc/init.d/rc.mod
tmp_permissions() {
# re-set /tmp permissions as AVM overwrites them to 0755 somehow after var.tar unpacking
chmod 1777 /var/tmp
}

[fraternl]

Either the permissions are never set sometimes or they are reverted soon after.
This is the output of a box I just restarted.

# uptime
11:55:03 up 7 min, load average: 0.35, 0.82, 0.56
# stat -c %a /var/tmp
755
# grep chmod /etc/init.d/rc.mod
chmod 1777 /var/tmp
#

[fraternl]

In the startup script of the daemon that's running as a non-privileged user I have inserted the line chmod 1777 /var/tmp
I need to wait however some time before I can apply that new firmware to all those boxes as those are production environments.

In the meantime I've already applied a chmod 1777 /var/tmp manually on the boxes that are now on 0755
I will find out soon if those permissions change during their uptime.

[fraternl]

I think it's a timing issue.

You could replace "chmod 1777 /var/tmp/" in /etc/init.d/rc.mod with this:

echo -e "chmod 1777 /var/tmp\nsleep 60\nchmod 1777 /var/tmp\nrm /tmp/chmod.sh" >/tmp/chmod.sh
/bin/sh /tmp/chmod.sh &

It will create a mini-script which sets the permissions, waits a minute and sets it again and removes itself. (this message will self-destruct....)

It then calls the script deamonised, so it doesn't halt the process in /etc/init.d.rc.mod.

In the meantime I will keep all my boxes monitored and will let you know if one of these boxes reverts to 0755 without having restarted.

[fda77]

https://freetz-ng.github.io/freetz-ng/NEWS.html#2020-11-18
You could add simply a sleep into rc.custom and then run sh /etc/onlinechanged/10-tmp_permissions online. Or a chmod by cron.
But as nobody knows when avm reset the permissions, the best is to use libctlmgr what currently is not possible

The "sleep 60" may work for you, but other devices could take longer, eg a common crapp telekom connection needs 170seconds to synchronize

[fda77]

On my 7490 /tmp is still 1777 after 1h uptime, without additional things like rc.custom or cron

[fraternl]

Well, it does the chmod immediately and then repeats it after a minute.

As I wrote. I have it monitored on 60+ boxes.
None of them changed during their uptime.

For now, my guess is that it just goes wrong on startup, but not always.

It could be it's doing it too early sometimes.

[fraternl]

I just have my first box that reverted to '755'
It's a box that has a cronjob for a reboot each morning at 6:25
None of the other many boxes have thus far reverted to '755'

[fraternl]

I have my first box with an uptime of more than a day which had its permissions changed after a day (?).

# stat -c %a /var/tmp
755
# chmod 1777 /var/tmp
# uptime
 09:30:30 up 1 day, 40 min,  load average: 2.54, 2.49, 2.40

This confirms that there's a need to keep it at 1777

BTW I still do not know if you assumed it could be changed during runtime by AVM or that you knew it gets changed.

EDIT
I just now assigned a "always give device the same IP" using the AVM webif and I noticed the permissions of /var/tmp changed to 755

[fraternl]

I have modified the script that's run with "sudo" and added this line:

[ `stat -c%a /var/tmp` -ne 1777 ] && chmod 1777 /var/tmp && date >>/var/tmp/chmod1777

This script is invoked each 10 minutes and is also the script which needed permission to write on /var/tmp
The script is placed in /bin and is read-only

The chmod is only run when it's not 1777 and it will get logged (in /var/tmp however)

It's not a generic solution, but one for my specific use-case

[fda77]

The best solution is to prevent the ctlmgr to prevent to execute "chmod". When libctlmgr works with supervisor (fos 7.2+) again this should be fixed. As this need much time to test i've not planned to do it this year
https://github.com/Freetz-NG/freetz-ng/blob/master/make/libs/libctlmgr/Config.in#L11
You could compile the lib with (only) this option and run ctlmgr with it

[fraternl]

I needed to read the thing you wrote several times to understand the concept.
Not sure if I do now, but I think you mean this.

Is this correct?

libctlmgr is called by the process ctlmgr

By selecting the FREETZ_LIB_libctlmgr_WITH_CHMOD=y I will get another library which will be used by ctlmgr
this library has code in it which sets 1777 to /var/tmp

Am I correct in thinking I have to do this by adding this line to .config and I can't select it with make menuconfig??

FREETZ_LIB_libctlmgr_WITH_CHMOD=y

Still, it's not clear to me why this isn't a final solution and what you will be doing later on.

[fda77]

The current wrapper things needs to be changed fpr svctl (supverviser like systemd) compatibility, but this need much time i dont have currently

[fda77]

libctlmg_svctl.patch

I've found this from some older tests. You sould enable developer+disable the watchdog. ctlmgr will crash, run it verbose and in foreground to see it.
Feel free to fix!

[fraternl]

It seems the permission setting of /var/tmp in /etc/init.d/rc.mod is too early.
I've changed tmp_permissions() in rc.mod to this:

tmp_permissions() {
        # re-set /tmp permissions as AVM overwrites them to 0755 somehow after var.tar unpacking
        chmod 1777 /var/tmp
        # create script which will set permissions the upcoming 10 minutes if it changes
        echo -e 'n=1\nwhile [ $n -lt 20 ] ; do\nsleep 30\n[ `stat -c%a /var/tmp` -ne  1777 ] && chmod 1777 /var/tmp && echo "$n `date`" | tee -a /var/tmp/perm-tmp\nlet n+=1\ndone\nrm /var/tmp/chmodtmp.sh' >/var/tmp/chmodtmp.sh

        # run script daemonised
        /bin/sh /var/tmp/chmodtmp.sh &
}

I know this doesn't fix the changing of permissions by ctlmgr somewhere later on.
it creates a script with a loop of 30 seconds and logs when it comes in action.

 cat perm-tmp
1 Sun Nov 12 18:24:47 CET 2023

Other box

cat /tmp/perm-tmp
2 Thu Jan  1 01:02:21 CET 1970

The first digit shows at which try it needs to set the permissions again.
It seems the original setting of the permission is only a bit too early

I know I need to fix this a proper way, but I also need a fix now for all the production boxes I have...

The script /sbin/wifion is run every 10 minutes and it is also the script which runs with sudo and needs to write to /tmp
The script starts with checking the permissions of /var/tmp and if it's not 1777 it will change it into it and then writes to the log /tmp/perm-tmp....

I didn't think of it when I wrote the script, but the non-privileged sudo user shouldn't be able to write to /var/tmp/perm-tmp as it already exists, was created by root and only has write privs for the root user.

I assumed the sticky bit would prevent it writing to it as a non-privileged user.

I did a test on a mature linux machine and I was unable to write to a file created by root in /tmp
It seems it doesn't work that way on this linux box.

head /sbin/wifion

#/bin/sh
#
[ `stat -c%a /var/tmp` -ne 1777 ] && chmod 1777 /var/tmp && echo "$0 `date`" >> /tmp/perm-tmp

WIFION=`/usr/bin/ctlmgr_ctl r wlan settings/ap_enabled`
[ "${WIFION}" == '0' ] && echo 0 && exit 0

TMP1=`mktemp` 2>/dev/null || TMP1=`mktemp --tmpdir=$HOME`

root@:/tmp# ls -l /var/tmp/perm-tmp
-rw-r--r--    1 root     root           136 Nov 13 10:50 /var/tmp/perm-tmp

root@:/tmp# cat /var/tmp/perm-tmp
/var/tmp/chmodtmp.sh 1 Thu Jan  1 01:02:11 CET 1970
/sbin/wifion Mon Nov 13 10:00:59 CET 2023

root@:/tmp# stat -c%a /var/tmp
755

root@:/tmp# stat -c%a /var/tmp
1777

root@:/tmp# cat /var/tmp/perm-tmp
/var/tmp/chmodtmp.sh 1 Thu Jan  1 01:02:11 CET 1970
/sbin/wifion Mon Nov 13 10:00:59 CET 2023
/sbin/wifion Mon Nov 13 10:50:59 CET 2023
root@:/tmp#