[feisty] command line apt-get/aptitude breaks update-manager with certain umask settings

[sardion]

Binary package hint: apt

Using the command line apt-get or aptitude to do pretty much anything results in a file /var/lib/apt/extended_states being created and empty. The update-manager (and apt-get and aptitude) then choke on a "bad file descriptor" error for that file. If I manually remove the file (sudo rm /var/lib/apt/extended_states) then everything is fine.

This started shortly after upgrade to feisty. Upgrade also corrupted my pkg_cache.bin files but removing those just once fixed that issue.

Can anyone confirm?

[Michael Vogt (mvo)]

Thanks for your bugreport.

I can not reproduce this problem here. Are you using the edgy versions of apt-get/aptitude? Do you use any other frontends (like synaptic/adept)? I currently have no idea why it empty that file.

What should happen is that if you e.g. install:
$ sudo apt-get install 3ddesktop
it should bring in libimlib2 and that should be then marked in /var/lib/apt/extended_states as Auto-Installed

Cheers,
 Michael

[John Vivirito (gnomefreak)]

Unmarked as a duplicate as there is no way to know if it is the same problem.

[John Vivirito (gnomefreak)]

Can you please attach the crash log for apt from /var/crash to this bug report using the Comment/Attach Files link on the top left of this page.

[sardion (ubuntu-sardion)]

Problem persists.

I do not think it is the same as the other since there is no segfaulting, just this empty extended_states file.

If no one can reproduce then I suspect it is an artifact of upgrading. I did make the mistake(?) of upgrading to feisty but leaving edgy-security in my sources. Everything is now up to date feisty but still this problem.

I will attempt a clean install if no one else has this issue.

[sardion (ubuntu-sardion)]

There is no crash log for apt. Apt works fine.

Update-manager crashes. I can attach the log if you want, but it all boils down to the last line:

SystemError: E:Could not open file /var/lib/apt/extended_states - open (13 Permission denied), E:Unable to determine the file size - fstat (9 Bad file descriptor)

[root@wizardry:/var/crash]% ls -l /var/lib/apt/extended_states
-rw-r----- 1 root root 0 2007-01-12 17:58 /var/lib/apt/extended_states

Whenever I run aptitude from the command line (as root or via sudo, it creates the file extended_states but leaves it totally empty).

At present, I simply delete the extended_states file before running update-manager. Command line works fine by itself, update-manager fine by itself. Trying to mix them leads to the problem.

[sardion (ubuntu-sardion)]

Further messing about shows that if I forcibly chmod extended_states to allow a+rw then all seems well.

This bug seems to be that if aptitude is run as root from the command line, it creates extended_states in such a way that update-manager cannot access it.

[sardion (ubuntu-sardion)]

Update: I have nailed down the issue.

I have root's umask set to 027
When I run aptitude remove ... as root
this results in the file
/var/lib/apt/extended_states
being recreated using that umask which then makes update-manager crash since it cannot read said file.

Possible solutions: 1) require root's umask to allow read access to everyone (BAD) or 2) modify aptitude to create that file world readable (BAD) or 3) make update-manager use sudo (or equiv) to read that file (it must use sudo somehow to do the updates anyway)

To recreate: set root's umask to 027 and run aptitude remove xxx from command line as root then launch update-manager.

[Michael Vogt (mvo)]

This is fixed in feisty.

The extended_states file is just like the lists files readable by default for others (0644) now regardless of the umask.

If someone has concerns about this, he can always chmod 0700 /var/lib/apt (but this will break tools like update-manager).

Cheers,
 Michael