Re: [Compilercache-general] RFC: suggestion for secure tmp file creation

[Erik T. <er...@er...>]

hi!

On Tue, Nov 20, 2001 at 08:17:08PM +0100, Jochen Voss wrote:

>     Package: compilercache
>     Version: 1.0.9-2

1.0.10 is the new one? sorry i didn't check if .deb is available. i
always didn't understand why software writers didn't even check their
.debs if others make them for them, but nowadays as Jochen makes .debs
for my software i understand why software developers don'T check them
:)

first it's extreme lazyness. that's probably the main reason. second i
use my own installation, since that's what i always did with that
software. third i update my code sometimes which would mean removal of
the .deb.

but mainly it's lazyness - shame on me :-)

>     Severity: normal

change severity to wishlist or close the bug :-)

>     With 1.0.9-2, you (wisely) moved the cache directory to the user's
>     home directory to avoid security problems. However, some users will
>     still want to have the directory in /tmp so that cache entries are
>     expired automatically. If they do put the cache in /tmp, the patch
>     below will increase security by first creating the directory and then
>     checking whether it is owned by the user.

i don't like this. in 1.0.10 you can configure where to put your cache
data. nobody forces you to do anything in /tmp. but if you want to,
you may do it. now the additional functionality must be activatable by
a config option. because a user putting his cache in his home dir
obviously does not want this kind of checking. so there's another new
option, which i think is not useful and just confusing users.

it's better to have private clean scripts that clean your own cache on
a regular basis (cron or login) than to move the stuff to /tmp by
force, no matter how complicated this is, just to have it
automatically cleaned on boot. and by the way, cleaning the WHOLE
cache on boot just sucks. what you really want is cleaning some week
old cache entries. and not just a complete wipe out on reboot.

so the extra effort seems to be useless.

the private clean script stuff is in the todo for 1.0.11

>     I believe this makes cache dirs in /tmp secure as long as the cache
>     dir is in /tmp itself (/tmp/compilercache_$USER) and not in a further
>     subdirectory (/tmp/somedir/compilercache_$USER). The worst thing that
>     can happen is a "denial of service" if someone else got there first
>     and created /tmp/compilercache_$USER files for all user names - not
>     really a problem in practice.

maybe. but i don't see the point in putting the cache to /tmp. other
cache programs like all internet proxies, e.g. squid don't put their
cache in /tmp either. /tmp is for erase-on-reboot temporary
files. cache entries are not erase-on-reboot temporary files.

>     This change breaks the ability to share a cache between >1 users. 
>     However, that is evil anyway, not only for security reasons, but also
>     because all sorts of "funny" problems can arise by different toolchain
>     versions being used on different machines.

this kind of "funny" thing cannot happen. the version of installed
compiler is used in the cache file name computation. if multiple
compilers with the same 'gcc -v' output produce different ".c" - ".o"
pairs then something else is wrong, not the compilercache.

as i am hearing this wrong argument very often i should emphasize it
in the readme i guess... or in the FAQ maybe. i added it to my TODO.

> [patch...]

> What do you think about this?  I think this
> should not be implemented directly, because it
> looses the possibility to share cache directories.
> But maybe the best solution would be, to add a
> new option to the configuration file: if you would
> set YES_PLEASE_CHECK_THE_CACHE_DIR_OWNER=1, the
> above check could be enabled, and be disabled otherwise.
> So again, what do you think?

i think that option is not neccesary.


cu
erik

-- 
Name:  Erik Thiele                                        \\\\
Email: er...@er...                                 o `QQ'_
WWW:   http://www.erikyyy.de/                              /   __8
                                                           '  `