Rename mislukt als er geen symlinks in het pad zitten.

[Mijzelf]

Dit wordt een tamelijk lang verhaal, sorry.

Ik ben aan het rotzooien met een embedded Linux doosje (een Belkin Home Base), en liep daarbij tegen een raar verschijnsel.

Dit doosje slaat de instellingen op in een mtd block, in rauw formaat.

code:

ROOT_PASSWORD=<snip>
HOST_NAME=HomeBase
TIMEZONE=+0:00
USE_DHCP0=ENABLE
IPADDR0=0.0.0.0
NETMASK0=0.0.0.0
GATEWAY=0.0.0.0
DNS_PRIMARY=0.0.0.0
DNS_SECONDARY=0.0.0.0
HTTP_PROXY_ADDR=
HTTP_PROXY_PORT=
NTP_SERVER=0.pool.ntp.org

en zo verder, 65 regels. Bij het opstarten word dit gecached in een platte text file, /etc/sysconfig/system.conf.

Het rootfs is squashfs, en de /etc directory bevat een aantal symlinks naar /tmpfs/etc/... voor de files die writable moeten zijn. /etc/sysconfig is dus een symlink naar de directory /tmpfs/etc/sysconfig. Op /tmpfs is een tmpfs gemount. (ja echt!)

Nu heb ik de hele /etc directory writable gemaakt. Dit heb ik gedaan door de squasfs mtdblock nogmaals te mounten op /.rootfs, en /tmpfs/etc te bindmounten op /etc. Vervolgens heb ik in /etc symlinks gemaakt naar alle files/directories in /.rootfs/etc. De files die al symlinks waren heb ik vervangen door echte, lege, files.
De directory /tmpfs/etc/sysconfig bestaat dus nog steeds, en heeft nog dezelfde functie.

Na deze ingreep kon ik geen instellingen meer veranderen. De webinterface waarmee dit gedaan had moeten worden crashed met een witte pagina met daarin de naam van 1 van de variabelen, bijvoorbeeld USE_DHCP0.
In /var/log/messages staat de volgende regel:

code:

Jun  3 17:13:42 HomeBase user.crit result_main.htm: Rename config file fail master /etc/sysconfig/system.conf tmp /tmp/conf.tmp.yDazMa

Inderdaat bestaat de file /tmp/conf.tmp.yDazMa, en deze is identiek aan /etc/sysconfig/system.conf, op de settings die veranderd zijn na. Blijkbaar had deze naar /etc/sysconfig/system.conf gerenamed moeten worden, en is dit mislukt.

Nu heb ik de directory symlink hersteld:

code:

mv /etc/sysconfig /etc/.sysconfig
ln -s /tmpfs/etc/.sysconfig /etc/sysconfig

Dat lost het probleem op. Ik kan weer instellingen opslaan.

Maar nu is de vraag: Welk mechanisme kan ervoor zorgen dat een rename mislukt als er geen symlink in het pad zit, en slaagt als die er wel zit?

[Hero of Time]

Heb je gekeken naar de rechten op de betreffende bestanden? Wellicht dat dat je probleem is, en niet de symlink an sich.

[thunder7]

Weet je zeker dat de onderliggende hardware writable is? Als er een symlink naar één of andere ramdisk wel werkt met rename, en een directe verwijzing naar flash niet, dan wil dat misschien zeggen dat die flash-disk gewoon niet zomaar writable is?

[Mijzelf]

@Hero Of Time: De rechten van /tmpfs/etc/sysconfig zijn drwxrwxrwx, van /tmpfs/etc/sysconfig/system.conf -rw-------. Alles is eigendom van root, en de webinterface background draait ook als root. Eigenlijk is root de enige gebruikte user.
En ik heb letterlijk alleen

code:

mv /etc/sysconfig /etc/.sysconfig
ln -s /tmpfs/etc/.sysconfig /etc/sysconfig

gedaan om het weer te laten werken, hierbij worden volgens mij geen rechten veranderd.

@thunder7: Het squashfs rootfilesystem is zeker niet writable. Vandaar de symlinks naar het tmpfs op /tmpfs. De flash waarin de settings worden opgeslagen is dat wel, min of meer. Met mijn symlink aanpassing slaat hij de settings gewoon op.

(Het is me overigens nog niet duidelijk *hoe* die settings worden opgeslagen. Er is een (character)devicenode /dev/sxeeprom, en 'cat /dev/sxeeprom' levert me de inhoud /tmpfs/etc/sysconfig/system.conf, plus een hoop junk. Mogelijk dat het wegschrijven gewoon 'cat /tmpfs/etc/sysconfig/system.conf >/dev/sxeeprom' doet,
Er zit in de kernel source een behoorlijk fuzzy driver hiervoor, die gebuik maakt van 2 stuks 8k grote mtd partities.)

[Demo]

Waarom wil je het config-systeem uit elkaar trekken? Ik denk dat je eens in de boot/shutdown-scripts moet gaan neuzen, of het ding inderdaad de config in /dev/sxeeprom ophaalt/wegschrijft.

[Mijzelf]

Demoniac schreef op maandag 04 juni 2012 @ 13:12:
Waarom wil je het config-systeem uit elkaar trekken?

Omdat het kan. Dit doosje heeft 4 usb poorten en een ethernet poort, en zijn doel is (onder andere) om aangesloten usb schijven via samba met het netwerk te delen. Maar natuurlijk kan er veel meer, dus heb ik om te beginnen gezorgd dat hij een eventueel fun_plug.sh script op een usb disk zal uitvoeren. Toen liep ik er al snel tegenaan dat je vanuit zo'n script dingen wilt veranderen in /etc, wat de noodzaak oproept om /etc in ram te hebben, en ...

Ik denk dat je eens in de boot/shutdown-scripts moet gaan neuzen, of het ding inderdaad de config in /dev/sxeeprom ophaalt/wegschrijft.

Het móét wel. Tenzij 'ze' een methode hebben ontwikkeld om de flash buiten het devicenode systeem om te benaderen. En waarom zouden ze? Het is duidelijk dat de settings achter /dev/sxeeprom zitten. Uit de kernelsource blijkt duidelijk dat er zowel een character interface als een block interface aan de flash hangt. De block interface wordt uitsluitend gebruikt voor het rootfs, en de character interfaces voor settings en firmware updates.

'Delicate zaken' als settings uit de flash lezen en wegschrijven worden helaas in gesloten binaries gedaan, dus daar kan ik niet bij. Maar eigenlijk hoef ik dat ook niet te weten, zolang de firmware maar blijft werken. Mijn eigen settings zet ik wel op een usb disk.

[Demo]

Zie je mogelijkheid om de squashfs te overschrijven? Dan kan je 'm op een ander systeem uitpakken, modificeren, weer inpakken en op je device zetten. Dan heb je in ieder geval je config-files er op..

[Hero of Time]

Mijzelf schreef op maandag 04 juni 2012 @ 11:20:
@Hero Of Time: De rechten van /tmpfs/etc/sysconfig zijn drwxrwxrwx, van /tmpfs/etc/sysconfig/system.conf -rw-------. Alles is eigendom van root, en de webinterface background draait ook als root. Eigenlijk is root de enige gebruikte user.
En ik heb letterlijk alleen

code:

mv /etc/sysconfig /etc/.sysconfig
ln -s /tmpfs/etc/.sysconfig /etc/sysconfig

gedaan om het weer te laten werken, hierbij worden volgens mij geen rechten veranderd.

Daar ligt denk ik wel je probleem. Rechten met rw------- geeft niet veel goeds weer in dat opzicht. Is de oude map ook echt zo? Wat krijg je als je de bestanden chmod naar 666? Zie je ook in de apache config dat de gebruiker root is, en niet www-data oid? Zie je andere gebruikers in /etc/passwd?

Je hebt het er ook over dat je commando geen rechten verandert, maar je wijzigt ze wel degelijk. Je verander namelijk de map /etc/sysconfig voor /tmpfs/etc/sysconfig, een map die op een volledige andere plek staat, met z'n eigen rechten.

[Mijzelf]

Hero Of Time schreef op maandag 04 juni 2012 @ 21:58:
[...]

Daar ligt denk ik wel je probleem. Rechten met rw------- geeft niet veel goeds weer in dat opzicht. Is de oude map ook echt zo?

/tmpfs/etc/sysconfig/system.conf is een file, en die wordt door de firmware ergens tijdens boot aangemaakt met deze rechten. Dit dus zowel in de werkende als in de niet-werkende situatie.

Voor de duidelijkheid: zowel in de originele situatie als in de nieuwe bevinden de files zich in /tmpfs/etc/sysconfig/, en de inhoud wordt door de firmware in de startscripts aangemaakt.
Het verschil is dat in de oude situatie /etc/sysconfig een symlink is naar /tmpfs/etc/sysconfig, terwijl in de nieuwe situatie /tmpfs/etc is gebindmount op /etc.

Wat krijg je als je de bestanden chmod naar 666?

Zal ik proberen. Maar dat is dan een actie van mij, nadat een firmware startscript het bestand met andere rechten heeft aangemaakt.

Zie je ook in de apache config dat de gebruiker root is, en niet www-data oid? Zie je andere gebruikers in /etc/passwd?

Apache? Kom nou, het doosje zakt al door zijn knieen als hij er aan denkt.
Dit doosje draait

 thttpd - tiny/turbo/throttling HTTP server
                    version 2.25b of 29dec2003

en de configurie file:

dir=/var/www
nochroot
nosymlink
user=root
logfile=/dev/null
pidfile=/var/run/thttpd.pid
port=80
charset=""
cgipat=**

Volgens top draait alles behalve avahi als root. Volgens passwd zijn er meer users: root, bin, ftp, avahi, avahi-autoipd, nobody en administrator.

Je hebt het er ook over dat je commando geen rechten verandert, maar je wijzigt ze wel degelijk. Je verander namelijk de map /etc/sysconfig voor /tmpfs/etc/sysconfig, een map die op een volledige andere plek staat, met z'n eigen rechten.

/etc/sysconfig was nooit een map, maar een symlink. De echte sysconfig heeft altijd in /tmpfs/etc/ gestaan.

Ik zal eens gaan kijken of ik strace gecompileerd krijg voor dit doosje, en of ik het onder de cgi binary geschoven krijg. Misschien controleert hij wel letterlijk of /etc/sysconfig wel een symlink is.

[Mijzelf]

Met wat moeite heb ik strace eronder kunnen draaien, en dit is de failure:

rename("/tmp/conf.tmp.3HznzF", "/etc/sysconfig/system.conf") = -1 EXDEV (Invalid cross-device link)

Blijkbaar is door de bindmount Linux de kluts kwijt over welk device nou wat is. /tmp en /etc/sysconfig zitten toch echt in hetzelfde tmpfs.

[Hero of Time]

En is het oorspronkelijk ook zo? Je hebt wat aangepast, en hierdoor mogelijk de mounts waar 't op controleert.

[Mijzelf]

Ja.
Oorspronkelijk was:
* Readonly rootfs:
/tmp -> symlink naar /tmpfs/tmp
/etc/sysconfig -> symlink naar /tmpfs/etc/sysconfig
/tmpfs -> Lege directory.
* Startscript doet o.a:
mount -t tmpfs tmpfs /tmpfs
mkdir -p /tmpfs/tmp
mkdir -p /tmpfs/etc/sysconfig

Nieuw:
* Readonly rootfs:
/tmp -> symlink naar /tmpfs/tmp
/etc/sysconfig -> bestaat niet
/tmpfs -> Lege directory.
* Startscript doet o.a:
mount -t tmpfs tmpfs /tmpfs
mkdir -p /tmpfs/tmp
mkdir -p /tmpfs/etc/sysconfig
cp -a /etc/* /tmpfs/etc/
mount --bind /tmpfs/etc /etc

De uiteindelijk failure is volgens spec, heb ik inmiddels gevonden: rename(2) - Linux man page:

EXDEV
oldpath and newpath are not on the same mounted file system. (Linux permits a file system to be mounted at multiple points, but rename() does not work across different mount points, even if the same file system is mounted on both.)

Dus die bindmount deed het hem.

[Hero of Time]

Rtfm he? Zo lullig dat je lang bezig bent en even de man page lezen had je direct 't antwoord .

[Mijzelf]

Jah. Alleen jammer dat het oorspronkelijke probleem nauwelijks een hint gaf welke manpage het dan zou moeten zijn.

[Hero of Time]

Dat is denk het ergste idd.