File: BUGS

package info (click to toggle)
fakeroot 0.0-17
  • links: PTS
  • area: main
  • in suites: slink
  • size: 160 kB
  • ctags: 189
  • sloc: ansic: 690; cpp: 543; makefile: 126; sh: 68
file content (68 lines) | stat: -rw-r--r-- 2,647 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
BUGS: 
  
i=1;while let "i<1000"; do mkdir $i; mkdir $i/$i; let "i=i+1"; done   
i=1;while let "i<1000"; do /usr/bin/touch $i; let "i=i+1"; done   
i=1;while let "i<10000"; do echo > $i; let "i=i+1"; done   
i=1;while let "i<300"; do /bin/echo > $i; let "i=i+1"; done   
i=1;while let "i<300"; do /bin/echo -n n; let "i=i+1"; done   
while /bin/ls  >/dev/null; do let "i=i+1"; done   


No bugs, I hope, just shortcomings:


  - It will not do "rm /etc/passwd", nor will it create files
    in directories where the user who started fakeroot didn't
    haver write permissions.

  - when doing "chmod u+s file; echo h >> file", the setuid bit
    of file doesn't get cleared.

  The above problems (and probably many more) are of no importance
  when using "dpkg-buildpackage -rfakeroot", but your systemadmin may
  be suspicious if you claim to have broken his sytem, but the uid=0
  you obtained cannot write to /etc.

------------------------------------
notes:


tricks/hacks:
  -open/create:
    by default, files are created/opened still with the real user
    as owner. I should wrap open/create to get around this,
    but I took the easy way out: any "unknown" file that's
    stat-ed has uid 0 and gid 0. Should be fine most of the
    time, I think.
  -I intentionally didn't wrap "chdir". This would make
   stuff like chdir("dir"); unlink("file") work better
   (to delete "dir/file"), but the daemon would have to have
   an array of cwd's for each child process, and would have to
   know what the parent of each child is (child inherits cwd).
   makes everything a lot more complex than just doing a lstat
   before the unlink/chmod/chown.


--debian: 
  according to the Debian guidelines, no files should
  be unreadable by anyone on the system (mode 644 is a minimum), 
  and directories should at least have mode 700. 
  If --debian is specied, fakeroot generates an error when an attempt
  is made to violate these rules.


Testing:

For yet another testrun, I typed "./fakeroot /bin/bash -l" in
my lower xterm. Dammit, loads of "mesg: can't resolve symbol '_dl_open'" 
error messages (and I get my prompt back). Apparently root runs
"mesg n" in his ~root/.bash_profile. So, I go to my upper xterm,
check (as non-root) what rc file the "mesg n" is in, and after
conferming that it indeed is in ~root/.bash_profile, I am about
to type "su root" in the upper xterm, to fix it. But then I
notice the root prompt in my lower xterm, and think, hey, I
already have a root session running -- saves me typing that root
passwd again. Going to my lower xterm, I realise that that
root-prompt came from "fakeroot": it actually worked!