summaryrefslogtreecommitdiff
path: root/storeio/pager.c
diff options
context:
space:
mode:
authorJustus Winter <4winter@informatik.uni-hamburg.de>2013-08-15 18:41:51 +0200
committerSamuel Thibault <samuel.thibault@ens-lyon.org>2013-09-15 23:47:40 +0200
commitb2e27fcee4cec98ffc39273ecfaa73aace9da2c3 (patch)
tree07b09422bd01aab1695b5bd72ef3a56858e0afb6 /storeio/pager.c
parent23ca8f5f942f831ec5be3667fd0a29873fae2912 (diff)
exec: remove support for transparently ungziping executables
Remove support for transparently ungziping executables from the exec server. The code in question makes the exec server unnecessarily complex and since the exec server is an essential process, crashing it makes /hurd/init crash the whole system. Since the gzip code is not thread-safe, all access to it is serialized, so there is a trivial way for one user to delay another users gzipped executables for some unspecified time. This can be accomplished by padding any program with easily compressed data, zipping it and executing it. Using such a program as an passive translator and then triggering its execution by the filesystem translator also stalls any requests to that filesystem (observed using the libdiskfs-based ext2fs). Since compressed executables cannot be mapped into the memory, they have to be uncompressed into allocated memory first. This is slower and any user with access to the exec server can make it allocate arbitrary amounts of memory. If the Hurd had proper memory accounting, this would probably be a way around it. So the compression support in exec seemingly creates various issues for little value, at least with the abundance of nonvolatile memory available today. * exec/Makefile: Remove gzip related files. * exec/exec.c: Remove anything #ifdef GZIPped. * exec/unzip.c: Move to libstore. * exec/crypt.h: Likewise. * exec/gzip.h: Likewise. * exec/inflate.c: Likewise. * exec/tailor.h: Likewise. * exec/util.c: Likewise. * libstore/Makefile: Remove the vpath magic for looking up the zip stuff.
Diffstat (limited to 'storeio/pager.c')
0 files changed, 0 insertions, 0 deletions