Ticket #5637 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

orphaned files

Reported by: walter Owned by: mstone
Priority: blocker Milestone: Update.1
Component: security Version:
Keywords: rainbow-integration Cc: ivan, jg, bernie, mstone, cscott
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Change History

Changed 7 years ago by jg

  • cc jg added
  • priority changed from high to blocker
  • milestone changed from Never Assigned to Update.1

This seems pretty serious to me. How hard is it to fix?

Changed 7 years ago by tomeu

If I correctly understand the issue, this is not a problem at all after ship.2. We stopped copying files to there and are hard linking them instead.

Could someone try to reproduce the issue in one of the update.1 builds?

Changed 7 years ago by tomeu

  • cc bernie added

But I guess we should anyway clean up that dir after booting, right?

Changed 7 years ago by bernie

What would be a reliable way to identify the orphaned files? We'd better be extra cautious when deleting user data.

Changed 7 years ago by tomeu

We don't need to delete any file. We wish to remove the hard links from that dir, because I guess every hard link takes up some space.

Changed 7 years ago by jg

The links take almost no space.

If there is a hard link to a file, even if the other link is removed, the space will not be freed...

So long as the link count is one or higher, files will not actually be deallocated.

Changed 7 years ago by tomeu

  • cc mstone, cscott added

I cannot see this happening any more in update.1 builds, although I guess some hard links could be leaked in /activities/uid_to_instance_dir/* by bad-behaved activities. I'm not sure if those directories are cleaned up when booting.

Perhaps Ivan has some plans for the new datastore that won't use hard links?

Anyway, I don't see this as a blocker for update1.

Changed 7 years ago by mstone

  • keywords rainbow-integration added

Changed 7 years ago by jg

tomeu, mstone: if this has been tested as fixed, then please close the bug...

Changed 7 years ago by marco

  • owner changed from tomeu to mstone
  • component changed from journal-activity to security

jg, not fully fixed yet.

Michael is going to see if we can have rainbow rm -rf the instance dir, as a solution for Update.1. (on the longer term we will have to revisit the exact activity instance lifecycle)

Changed 7 years ago by chihyu

I am creating test cases for this issue, but the original bug description has disappeared from the wiki. It will be great if someone could suggest how to test this issue, and whether it should be tested in Update.1.

Thanks a lot!

Test cases: http://wiki.laptop.org/go/Update.1#Security.2FUpgrades

Changed 6 years ago by gnu

The original problem, I think, is that the Datastore made copies of files that were deleted or opened from USB storage devices or SD cards. This was popular, as G1G1 people tried to play movies or music from USB disks or flash sticks. Copying in a 300MB movie, however, tended to fill the NAND filesystem. And then nothing deleted those copies of the files. These are the bugs: #5719, #5744. Here is another bug that mentions this issue, in the context of ship.1 to update.1 upgrades: #5955.

Recipe to reproduce:

  • Install Ship.1 build 650.
  • Plug in a USB stick containing a large file (e.g. the 128MB Ogg Theora from #5744)
  • Attempt to open that file (resulting in a copy in NAND).
  • Let the USB light stop blinking (Sugar is done copying).
  • Check "df" to see how much space is occupied, and check "du /home/olpc/.sugar/default/data/"
  • Eject (in journal) and physically remove the USB stick
  • Bring up a terminal, and upgrade to update.1.
  • Reboot into update.1
  • Check "df" to see how much space is occupied, and check "du /home/olpc/.sugar/default/data/"

to make sure that all the files are gone from there.

Changed 6 years ago by mstone

The rainbow side of this bug has been complete since rainbow-0.7.7.

Changed 6 years ago by mstone

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.