[Buildd-tools-devel] Bug#381695: dchroot: Invades users privacy in
default configuration
Helge Kreutzmann
debian at helgefjell.de
Sun Aug 6 15:30:15 UTC 2006
Package: dchroot
Version: 1.0.1-1
Severity: important
A while ago testing upgraded to 0.99.2-2, which was broken as it
a) required to quote all arguments to dchroot, thus breaking tab
completion and
b) verbosly logged the action of the users of dchroot.
I read in the BTS that a) was an error and an updated package was
release to sid. Until today, this package has not yet entered testing,
unfortunately. Thus I recompiled the current sid version today on my
testing system to get rid of a) and investigate b).
Unfortunately, b) is not yet fixed.
Before upgrading to 0.99.2-2 I could use dchroot to call binaries in
my sid ia-32 chroot from an ordinary user account without leaving any
trace in system logs (i.e., the only trace was in my bash history,
which I could set to an arbitrary length as ordinary user, and which I
could edit in case I want to remove an entry). Since 0.99.2-2 each
call of dchroot is logged, e.g.:
Aug 6 15:55:46 remaxp schroot[30014]: [ia32 chroot] (helge->helge) Running command: "/bin/bash -c mplayer /tmp/movie.rm"
in /var/log/messages.
Tracing usage of dchroot by logging login and logoff is standard unix
logging, i.e. I have no objection against
Aug 6 15:55:46 remaxp schroot[2884]: (pam_unix) session opened for user helge by helge(uid=1000)
But the current behaviour goes way beyond this. Now the system
administrator can easily see which programms with wich arguments where
issued by the users. This severly intrudes privacy of the user, who
even are unable to stop this (note about shell history above). For a
private machine this is less severe, but if employed in a working
environment, this could be used to trace (part of) the work of the
employees, which is illegal in many cases here in Germany (unless
specifically agreed in certain circumstances, in cases of immediate
danger, by court order or if a direct suspicion of abuse exists and
certain representatives of the employees agreed on a case-by-case
basis).
As a quick workaround for the moment you could (and should) add proper
logcheck entries (for e.g. /etc/logcheck/ignorde.d.workstation and so
on), where you screen out those messages. But before the release of
etch, dchroot must not emmit those messages (unless told so by a
certain flag, thats fine, as long as the behaviour is off by default).
Of course, multi arch, which would avoid the use of chroots in many
cases on amd64, would be the proper solution, but I doubt that this
can be done 'till Etchs release.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.7-grsec-cz01
Locale: LANG=de_DE at euro, LC_CTYPE=de_DE at euro (charmap=ISO-8859-15)
Versions of packages dchroot depends on:
ii libboost-program-options1.33. 1.33.1-4 program options library for C++
ii libboost-regex1.33.1 1.33.1-4 regular expression library for C++
ii libc6 2.3.6-15 GNU C Library: Shared libraries
ii libgcc1 1:4.1.1-5 GCC support library
ii liblockdev1 1.0.3-1 Run-time shared library for lockin
ii libpam0g 0.79-3.1 Pluggable Authentication Modules l
ii libstdc++6 4.1.1-5 The GNU Standard C++ Library v3
ii libuuid1 1.39-1 universally unique id library
ii schroot 1.0.1-1 Execute commands in a chroot envir
dchroot recommends no packages.
-- no debconf information
--
Dr. Helge Kreutzmann debian at helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20060806/710547a0/attachment.pgp
More information about the Buildd-tools-devel
mailing list