#6216 NORM Never A: Read doesn't show specific fonts of pdf file, which show up with rainbow disabled

Zarro Boogs per Child bugtracker at laptop.org
Sun Jan 27 21:32:22 EST 2008


#6216: Read doesn't show specific fonts of pdf file, which show up with rainbow
disabled
----------------------------+-----------------------------------------------
  Reporter:  HoboPrimate    |       Owner:  rwh           
      Type:  defect         |      Status:  new           
  Priority:  normal         |   Milestone:  Never Assigned
 Component:  read-activity  |     Version:                
Resolution:                 |    Keywords:                
  Verified:  0              |    Blocking:                
 Blockedby:                 |  
----------------------------+-----------------------------------------------

Comment(by AlbertCahalan):

 Replying to [comment:5 mstone]:
 > First, the intention is definitely to limit malloc() upon request. My
 current difficulty is that I'm not yet ready to make provisions for the
 "request" part because I haven't thought all the way through it. (Thoughts
 tend to appear in 'rainbow.txt' in the security repo as they become worth
 sharing).
 >
 > Second, the author of
 [http://lxr.linux.no/linux/Documentation/filesystems/tmpfs.txt
 filesystems/tmpfs.txt] suggests that creating unrestricted tmpfsen will
 likely result in deadlocks. Therefore, I propose to allocate tmpfsen
 limited to 5% of the physical ram (this is 1/3 the limit picked by
 /etc/fstab but is still much larger than the current limit of 1MB).

 This is not something that is good to enforce. The child is not helped by
 being unable to run programs that want lots of tmp space.

 Even if a deadlock is possible, so what? Activities can not be prevented
 from being unreliable. Kids will delete activities that cause trivial
 problems like deadlocks. I say "trivial" because this is something that
 can be fixed with the power button; there is no loss of privacy and not
 even a need to reinstall.

 > Next - about namespaces. If we continue to put activities in separate
 namespaces from sugar, then I agree that it makes a lot of sense to
 overmount /tmp for them. However, as I said in #1731, I think we're better
 served by dropping the use of separate namespaces and by mounting with the
 'mode', 'uid', and 'gid' options. The namespaces are nice because they
 automatically GC the mounts when the activity ends, but that elegance is
 probably not worth the frustration they've caused.

 This would be a bad change, because it ties you to the UID-based
 implementation. That implementation is limiting. One should not increase
 the difficulty of switching to SE Linux as the underlying mechanism.

-- 
Ticket URL: <http://dev.laptop.org/ticket/6216#comment:6>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system



More information about the Bugs mailing list