JFFS2 does not perserve directory permissions across reboots when using a custom /sbin/init.

[mstone]

On a clean build 542 (B4), the following is adequate for me to reproduce the bug:

(after booting, while logged in as root)

cp -f /bin/bash /sbin/init

after rebooting, via

/sbin/halt -fph

run

mount -o remount,rw /
umask 022
mkdir a
cp -la a b
ls -alF a b    # permissions should be 0755 and 0755, respectively
mount -o remount,ro /
sync
/sbin/halt -fph

and after a final reboot

ls -alF a b    # permissions will (incorrectly) be 0777 and 0700, respectively

[mstone]

dcbw suggests:

"Build kernel with CONFIG_JFFS2_FS_DEBUG=1 and show me _all_ output over a serial console as you mount it, mkdir, cp -al, umount, mount again, ls. Doing this on any empty, small flash device is recommended -- there's much too much noise if you use the full 1GiB NAND chip."

and also includes a patch to the jffs2 tree from an earlier problem that may work around this bug.

[dcbw]

You likely mean dwmw2 (Dave Woodhouse)

[dwmw2]

The crappy workaround should fix the directory which gets 0777 permissions -- that's because we weren't applying the process's umask when creating the directory (or indeed any inode -- you should see it with creat() too.).

The directory with 0700 permissions is something different. I cannot reproduce, hence the request to show me debugging output. You don't need to use the NAND flash -- if you can reproduce on a virtual device ('modprobe mtdram erase_size=8 total_size=64') all the better. Format the flash by using 'flash_eraseall -j /dev/mtd$X' before mounting it and doing the test. Log in over the serial console to type your commands, so that they're in the appropriate place in the serial log to make things easier to follow. Then also show the output of 'hexdump -C /dev/mtd$X'

[mstone]

Herbert Pötzl and I spent some time gathering debugging output. We have successfully reproduced the bug both on stock 542 images and on custom kernels running in QEMU (using your mtdram test device).

Strace logs of the commands

mkdir a
chmod 755 a

and

mkdir a
cp -la a b

reveal that when POSIX ACL support is enabled, 'cp -la' duplicates file permissions with a call like:

setxattr("mnt/b", "system.posix_acl_access"..., "\x02\x00\x00\x00\x01\x00\x07\x00\xff\xff\xff\xff\x04\x00\x05\x00\xff\xff\xff\xff \x00\x05\x00\xff\xff\xff\xff", 28, 0) = 0

whereas mkdir relies on the kernel's implementation of umask support to get the correct permissions.

In both cases, the dentries carry correct permission (0755) but these permissions are not propagated to the inodes. (We infer this from the fact that the permissions are not preserved across umounts.)

Disabling POSIX ACLs fixes the problem.

Note: mkdir() (which relies on the umask and which does not use POSIX ACL calls) behaves differently depending on the presence or absence of POSIX ACLs.

We have not yet tested the patch that you included in your previous email.

[dwmw2]

You have described the problem addressed by the above patch. I have observed that causing the originally-created directory to have 0777 permissions instead of 0755, because the umask wasn't applied.

I haven't seen your other symptom though -- the copied directory having 0700 permissions. Does it persist when you apply the above patch? And still go away when you disable POSIX ACLs? Can you show me precisely what's on the flash, and the debugging output of JFFS2 while it puts it there?

[mstone]

Disabling POSIX ACL support is an adequate work-around for this bug.

[dwmw2]

fix is http://git.infradead.org/?p=mtd-2.6.git;a=commitdiff;h=9ed437c50d89eabae763dd422579f73fdebf288d

[kimquirk]

Scott, is this the same problem we were working on the other day? Where I loaded Walter's VIP stick and then later, when I tried to upgrade, all the activities icons were gone and the note in the log said file permissions were wrong. If this is the same bug, then can someone tell us if this patch was ever committed to the build?

This would be much higher priority if it is the same bug.

[cscott]

Michael, I believe this bug has been fixed for a while, hasn't it? Please close if so.

Kim, this is certainly not the bug we saw. The VIP-build stick install had been broken for a while, probably since the 'rpm install' was added to it.

[mstone]

I am quite confident that this bug was fixed by turning off ACL support and that #3260 has a different root cause.

[mstone]

For the record, the fix we decided to use, namely, disabling ACLs, was included in build 553.