> > Well, if we do this, we need to make sure to handle the case where > > people do something like: > > > > chown -R 755 debian/tmp/usr/bin > > chown g+s debian/tmp/usr/bin/special-binary > > > > i.e. later commands would have to override previous ones. (probably > > obvious, but I just wanted to make sure this was kept in mind). > > The new commands would edit a list of permissions, that would be later > used by tar. We could set an env var to the path of the list...
Nearly. What I've done so far: A programme, "fakeroot", that works as follows: $ fakeroot /bin/bash This will execute /bin/bash[1], and set environmen varable "LD_PRELOAD" to a libfakeroot.so.0.0. This libfakeroot currently overloads only chown and lstat[2]. Now, when you type in the thus executed shell: $ chown root:users somefile this will call the wrapper "chown" function. this wrapper calls the real chown, _and_ it sends (via SYSV IPC calls) a message to the (still running) fakeroot "daemon". This daemon records the new fake onerships of the file in an internal variable. The idea is now that when you do $ ls -al somefile ls will call lstat("somefile", &buf), again the wrapper lstat[2] function gets executed that sends a message to the daemon, asking if it's got any extra information about "somefile". The daemon may then eighther return "no, don't know that file", or (as in this case) "root:users". Thus, the ls would output that the file is owned by root:users. Also any other programme that users (l)stat will think so, so we don't need to modify tar or anything. The final goal of cource is to be able to do $dpkg-buildpackage -rfakeroot and build that package! Problems: - see [1], and [2] - yes fstat and fchown will be somewhat of a problem, but I'll just have to overlod open() etc too, and keep a list of inodes/filenames. - I probably will go wrong for pathalogical cases like ln file1 file2 chown mail:sys file2 rm file2 ls -al file2 I doubt whether these are important, and even if they are, I guess it will be possible to get it right. Non-problems: The above mentioned problem, > > chown -R 755 debian/tmp/usr/bin > > chown g+s debian/tmp/usr/bin/special-binary isn't a problem: the library function chmod(2) is never called with arguments like g+s, but only with the full permissions (the user space programme chmod(1) does a stat(2) first). footnotes: [1] I currently don't have a libc6 bash, so that doesn't work. I've been testing it with "es" (yet another shell that I never heard of, but I'm the maintainer). [2] Well, I've olverloaded lstat all right, but it doesn't seem to get called don't know why yet. Why would chown() work and lstat() not? -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) #what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .