Ticket #2732 (closed defect: fixed)

Opened 7 years ago

Last modified 7 months ago

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

Reported by: mstone Owned by: mstone
Priority: normal Milestone: Update.1
Component: distro Version:
Keywords: jffs2, updates, security Cc: mstone, krstic, cscott
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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

Attachments

Change History

Changed 7 years ago by mstone

Changed 7 years ago by 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.

Changed 7 years ago by dcbw

  • owner changed from dcbw to dwmw2

You likely mean dwmw2 (Dave Woodhouse)

Changed 7 years ago by dwmw2

  • status changed from new to assigned

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'

Changed 7 years ago by 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.

Changed 7 years ago by 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?

Changed 7 years ago by mstone

  • priority changed from blocker to low

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

Changed 7 years ago by kimquirk

  • cc cscott added
  • priority changed from low to normal
  • milestone changed from Trial-3 to First Deployment, V1.0

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.

Changed 7 years ago by cscott

  • owner changed from dwmw2 to mstone
  • status changed from assigned to new

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.

Changed 7 years ago by mstone

  • status changed from new to closed
  • resolution set to fixed

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

Changed 7 years ago by mstone

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

Note: See TracTickets for help on using tickets.