file system permission flipped.

[jg]

OLPC build 568 firmware Q2C26

I was trying different screen depths for testing.

the "/home/olpc/Activities" directory ended up with drwx------ permissions, breaking Sugar's ability to do anything, even displaying the activity icons.

I'm suspicious that the file system dropped the rx bits; it's also conceivable that Sugar could have flipped the bits, but this seems less likely.

[jg]

closing: believed a duplicate of #3595

[jg]

mstone thinks otherwise.

[cscott]

We strongly suspect this bug is related to the VIP-build install procedure, which does a 'cp' from a mounted USB stick as root. My theory is that how the journal mounts the key has changed recently from permissions a+rx to permissions u+rx, and this caused the breakage.

[dwmw2]

Is this the same as #2732? There's a patch upstream -- I thought we'd worked around it for now just by turning off ACL support though.

[dilinger]

Replying to dwmw2:

Is this the same as #2732? There's a patch upstream -- I thought we'd worked around it for now just by turning off ACL support though.

It sounds like turning off ACL support did not help; the kernel version in build 568 is 2.6.22-20070830.1.olpc.bff51ac9801503a, yet the turning off ACL support was done on Aug 21.

http://dev.laptop.org/git?p=olpc-2.6;a=commitdiff;h=f16c87a0b2dde441babc45d1a1a502056196b301

[mstone]

None of the evidence we have gathered to this date implicate either JFFS2 or vserver.

VServer is unlikely to be involved because the corruption happened on a folder in /home, which is essentially never touched by things using vserver and because widespread use of vserver's CoW link-breaking did not occur until after build 575 (cscott).

JFFS2 is not known to be involved because the filesystem corruption we have observed thus far (#2732) was believed to be fixed in build 553, because no mechanism has been proposed for how JFFS2 could have corrupted the permissions bits, and because we have not seen any similar corruption since.

Therefore, the most likely explanation that we have yet identified is that the /home/olpc/Activities directory was correctly copied from a source directory that had permissions 0700.

[cscott]

As I wrote above in cscott, this bug was most likely caused by the VIP build install procedure, which definitely screwed with /home/olpc/Activities (a) as root, and (b) with /media/VIPINSTALL mounted so that all the files had 700 permissions. I don't have the script in front of me at the moment, but it did a cp -a, which would be sufficient to create this behavior.

The root source for the regression was either that (a) USB keys didn't use to have 700 permissions when mounted, but started to at some point, or (b) the VIP install procedure was run by Walter as user olpc in the dev console, but started being run as root in vt 1 after an RPM install was added to the procedure. I don't know which of these for sure was the trigger, and I am not *certain* that the VIP bits were installed on jg's laptop, but this seems the most reasonable explanation.

Closing the bug.