Comment 3 for bug 191299

On Wed, Feb 13, 2008 at 10:38:58PM -0000, Till Kamppeter wrote:
> Matt, this piece of code cannot change the ownershps and permissions of
> /, as it only modifies files which fit the mask .hplip*/

There are a few problems with that code.

1. It's modifying data in user home directories. Package maintainer scripts
should avoid doing this, because mistakes could damage user data, it's very
difficult to do correctly, and on some systems, there may be tens of
thousands of home directories on a remote server somewhere, which may not
even be accessible.

2. It's also attempting to do this for system users (including root!) which
is even worse, since modifying these home directories can catastrophically
damage the system.

3. It's reading /etc/passwd to get account data. This means that it doesn't
actually find all of the user accounts, because they might be in a database
(but it certainly does find the system ones)

4. The parser is buggy: it doesn't do proper shell quoting. What happens
if the line in /etc/passwd has shell metacharacters in it, like *?

$ line='user:x:123:123:Hello * World:/home/user:/bin/bash'
$ echo $line
user:x:123:123:Hello Desktop Documents Maildir Music PDF Photos Pictures Public Templates Videos public_html src temp texmf World:/home/user:/bin/bash

5. The find command is buggy: it doesn't quote properly either. What
happens if I happen to run apt-get upgrade from a directory which contains a
file called ".hplip"?

6. It ignores errors. If something did go wrong when this code (or an
earlier version of it) ran, I would have never noticed it until I happened
to come across the damage in my filesystem (as I now have).

> Matt, and anyone else who suffers this bug, please restore the
> ownerships and permissions of the root directory manually (root.root
> 755) and then install the newest HPLIP package (or do simply an auto
> update on your system, new HPLIP version is 2.8.2-0ubuntu1).
>
> Do the ownerships and permissions of / change again?

No, I am not able to reproduce the conditions this way, but with all of the
variables involved (including the state of the filesystem and the current
working directory), this doesn't tell us very much.

Regardless of whether or not it can be found to be the root cause of this
particular bug, the code I quoted should be removed from hplip.postinst.

--
 - mdz