[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