3.0.0.4.384.45717 removes X attribute in /jffs files

[Ronald Schwerer]

Maybe it's been mentioned before and I missed it. I just noticed that, on a reboot, all my executable files in /jffs and below had their X attribute removed. This includes the .asusrouter script I used to schedule some cron housekeeping. I believe this is a new "feature". I saw this on all three of my RT-AC68Us only after installing
3.0.0.4.384.45717. One is configured as the AiMesh network router, one is a node, and one is a repeater.

Has anyone else seen this and is there any way around it (other than installing Merlin)? If this was an intentional change by ASUS, I find it offensive. I want control of my hardware and my scripts are none of ASUS's business.

 

[dave14305]

RMerlin alluded to it here after release of that firmware.
[Release] Asuswrt-Merlin 384.11 is available

 

[Ronald Schwerer]

RMerlin alluded to it here after release of that firmware.
[Release] Asuswrt-Merlin 384.11 is available

Thanks for pointing that out. Yes, it seems that is at least part of what RMerlin was referring to. That's a long thread that covers many issues and I haven't gone all the way through it. The implication that installing 45717 could prevent switching to Merlin says there's more to this under the covers.

 

[RMerlin]

I know why Asus did this, and while it was with good intentions, it was a bad idea. They should have removed that change from future releases AFAIK.

The implication that installing 45717 could prevent switching to Merlin

No, it does not. Totally unrelated, and won't prevent switching either.

 

[Ronald Schwerer]

I know why Asus did this, and while it was with good intentions, it was a bad idea. They should have removed that change from future releases AFAIK.

So it sounds like it might be fixed in a future release. Until then, I'll just need to remember to chmod all my files and manually launch .asusrouter after each reboot.

 

[camedia]

This is really bad. I was on vacation and didn't notice it till today. I rely on .asusrouter and my own script to detect if wan0 is down and turn on a warning light behind my TV to avoid streaming video on wan1, a mobile hotspot.

 

[Ronald Schwerer]

This is really bad. I was on vacation and didn't notice it till today. I rely on .asusrouter and my own script to detect if wan0 is down and turn on a warning light behind my TV to avoid streaming video on wan1, a mobile hotspot.

I found several workarounds. The simplest one requires a USB stick or drive mounted to your router.
If necessary add a line in your .asusrouter script to add-back the X attribute to any local scripts it runs. Example:

chmod 744 /jffs/my_utility_script.sh  /jffs/my_other_script.sh

Now set a command to run whenever a USB storage device is mounted:

nvram set script_usbmount="chmod 744 /jffs/.asusrouter;/jffs/.asusrouter"
nvram commit

Reboot the router, and .asusrouter will run when the USB device auto-mounts. I assume the specified script_usbmount command will run each time a drive mounts, so you might need to consider the consequences of this if you have 2 USB drives, or you occasionally swap drives. To make sure it only runs once per boot cycle, add this before any critical code in your .asusrouter script:

mkdir  /home/root/.asusrouterlock || exit

 

[camedia]

Thanks. I used script_usbmount a year ago before I discovered .asusrouter on this forum. I just thought .asusrouter was more elegant.

You don't need chmod to execute a script. Using the shell is sufficient.

nvram set script_usbmount="/bin/sh /jffs/scripts/my_script.sh"
nvram commit

 

[camedia]

After installing firmware version 384.81039 it no longer removes the execute permission from the files, but /jffs/.asusrouter still doesn't run.

 

[Ronald Schwerer]

After installing firmware version 384.81039 it no longer removes the execute permission from the files, but /jffs/.asusrouter still doesn't run.

More "fixes" huh? Seems they intentionally want to break this capability. Well, as long as the script pointed to by script_usbmount works, I'm OK.

Haven't tried 384.81039 yet. Curious to see what else they broke.

 

[RMerlin]

More "fixes" huh? Seems they intentionally want to break this capability.

That script was a major issue, since it would still run after a factory default reset. So a single malicious or buggy script stored there would be next to impossible to remove by end-users. Removing it was the sensible thing to do.

 

[Ronald Schwerer]

That script was a major issue, since it would still run after a factory default reset. So a single malicious or buggy script stored there would be next to impossible to remove by end-users. Removing it was the sensible thing to do.

I always assumed /jffs got initialized during a factory reset. How about a physical NVRAM erase (holding WPS during power On)? I just have never tried because either of these since I didn't want to do it at the time.

 

[RMerlin]

I always assumed /jffs got initialized during a factory reset. How about a physical NVRAM erase (holding WPS during power On)? I just have never tried because either of these since I didn't want to do it at the time.

Neither will erase the jffs partition.

Sent from my SM-T720 using Tapatalk

 

[Gerard]

Is this issue fixed with firmware version 3.0.0.4.384.81049?

 

[Ronald Schwerer]

Is this issue fixed with firmware version 3.0.0.4.384.81049?

It depends on what you mean by "fixed". I have not installed 384.81049, but I briefly installed 384.81039. It no longer removed the 'X' attribute in /jffs, but it seems to of totally removed my .asusrouter script. I think this "feature" is also in 384.81049.
So they have changed the problem. As RMerlin stated - to keep malicious code from locking the router. Seems the best fix is to use

nvram set script_usbmount=some command

to execute a command when a USB device gets mounted.

By using an indirection to a removable device, the security concerns are mitigated since once the device is removed, you can regain control of a hacked router.

 

[Gerard]

I'm using a different technique to execute my script.

nvram set jffs2_exec=/jffs/boot_runscript

I will give firmware version 3.0.0.4.384.81049 a try.

 

[RMerlin]

I'm using a different technique to execute my script.

nvram set jffs2_exec=/jffs/boot_runscript

I will give firmware version 3.0.0.4.384.81049 a try.

That no longer works with 81049.