On Thu, May 03, 2001 at 01:33:06PM +0200, Jens Schmalzing wrote: > Presently, i.e. in the version I am working on, I use the approach of > the xserver-xfree86 package. If a configuration file exists, debconf > asks whether to overwrite it based on the answers to the following > questions. just so it will ALWAYS ask that question and not remember the answer, otherwise when the package is later upgraded the config file is again blown away. this violates policy. i don't know how the xfree86 packages work as i use potato (i hacked your sources packages a bit to build on pototo). the ones avialable now kept destroying my config file as i upgraded the packages a few times getting my potato hacks working right... it never asked me, it just remembered the first install's answer of `yes do auto config'... also i think its not necessary to run that horrible molvconfig program at every upgrade, once the vmodes file is built that should be considered good enough. if the admin changes something that requires rebuilding it then he can run the program himself. > Indeed. They use mktemp(1) now and should be safe. Then again, isn't > it one big security hole just to run MacOS? possibly... BenH says that the environment MacOS runs in is all fake, and isolated, MacOS software has no access to real hardware or anything related to the linux side of things. the only vulnerability he could think of is buffer overflows in MOL specific drivers which MacOS does interface with. in any event its probably only a good idea to let trusted users use mol, but that does not preclude the untrusted users who are NOT allowed to use mol from exploiting all the /tmp races. if mol is setuid i am sure there is a huge security hole, but your packages presently do not make anything suid. (well unless i broke something) as big and unaudited as mol is setuid is a very bad idea IMO. especially if its written as carelessly as that shell script wrapper.... also is that error file whose location is set in the wrapper script created securely by mol? (the ERRFILE=/tmp/.mol-errors or something like that) if not it should be moved to a mode 0755 root.root directory in /var/lib/mol or something, and out of /tmp. a couple other things, when --purged the package did not remove /etc/molrc and did not remove the /var/lib/mol directory (it was left empty) -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpgFD000DU__.pgp
Description: PGP signature