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: [EMAIL PROTECTED], [EMAIL PROTECTED] (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 [EMAIL PROTECTED] Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/
signature.asc
Description: Digital signature