macsat.com OpenWrt and ASUS WL Forum

After two unsuccessful attempts to install Debian on an internal disk on a Safecom SWSAPUR, I eventually found the reason for it: all file permissions on the disk had been changed to 777, i.e. full access for everyone, and sshd refused to work with a world-readable host key file.

I eventually tracked it down to the firmware: hotplug.sh executes a 'chmod -R 777' for any ext2/3 disk you attach to it! Short of wiping the disk (which the firmware occasionally did with ext3 partitions in previous versions) modifying it silently is about as bad a thing as an NAS device can do. What were Amit thinking there? Surely anyone who'd attach an ext2 disk would know to set the permissions as needed for sharing?!

Anyway, to fix that I downloaded Schufti's source for the 400s08 firmware version (MGB100schufti08.tar.bz2). Once I got it to build I removed those braindead chmod lines from hotplug.sh and rebuilt, which resulted in the attached firmware. (It's not really gzipped, but I renamed it to .gz because the forum software only allows certain file endings. Hence gunzipping it will fail. You might want to rename it to .img or .upg, although the firmware updater doesn't care anyway.)

Schufti, could you patch that bug/misfeature in future updates of your firmware?


ps: Anyone looking for a firmware build environment on Windows might want to take a look at andLinux (http://www.andlinux.org), which is a Ubuntu based on a coLinux (http://www.colinux.org) kernel that runs as a Windows app, which means that no VMWare or some such is needed. Additional packages can be installed as usual, through apt-get or synaptic from the standard Ubuntu repositories. Great stuff.

Hi,

you are not the first to complain about this "feature".

I agree that it might be an annoyance to you, but the device was never considdered to hold an OS on its attached mass storage devices. It only was ment to share data via various access methods. So AMIT simplified their live by guaranteeing sufficient rights to otherwise probably unaccessible files...

So I won't patch it as it most probably will break the original function for standard users; and all people wanting to use the box with "enhanced" Linux features are better off running the KK autobootfs.

I might consider making it configurable, if I can think of a simple way to do so.

schufti

Hi Schufti, I see your concern for backwards compatibility, but I think the severity of this bug trumps that. Even without trying to install an OS on a disk, I'd be upset if a device silently wiped all the permissions on it. Also, any users who manage to install a customised firmware in the first place and who then connect an ext2 disk are almost certainly capable of dealing with Unix file permissions themselves.

Besides, doesn't everything run as root anyway, thereby ensuring access no matter the file permissions? Otherwise, is there a way to automount partitions in such a way that permissions are ignored without actually wiping them on disk?

Hi,

no, access to file shares are not generally mapped to root user.

If you attach a mass storage device capable of "privileges" to a system with fixed privileges, there are some problems to be solved the one or other way. In general, I'd limited USB to FAT32 only.

And the internal hd was never intended to be under "direct access" of an "administrator" dealing with access privileges.

schufti

Greetings,
Is there a wiki on how to install Debian on the HD for this device?

Sanecyclist,
Could you briefly describe what you did after installing this modified firmware.

Thanks,
G.