Bug#625606: upower: resets block-device tunings on startup

2011-11-09 Thread Michael Biebl
Hi, Am 02.11.2011 16:26, schrieb Alexander Kurtz: The bottom line is that pm-utils should specify *both* device and dir when calling mount to avoid re-evaluating /etc/fstab which may be undesirable under certain circumstances (e.g. after doing a manual remount with different mount options).

Bug#625606: upower: resets block-device tunings on startup

2011-11-09 Thread Alexander Kurtz
On Wed, 2011-11-09 at 12:50 +0100, Michael Biebl wrote: You obviously care very much about this issue even if it only happens for some corner cases. Would you mind prepping a patch? I will definitely write a patch for this bug, however it might take two or three weeks until I have sufficient

Bug#625606: upower: resets block-device tunings on startup

2011-11-02 Thread Alexander Kurtz
tags 625606 security thanks Hi, this bug introduces a new security hole, consider the following example: # cat /etc/fstab [...] /home /mnt none bind 0 0 /home /mnt none bind,remount,ro 0 0 # mount -v -a [...] /home on /mnt type none

Bug#625606: upower: resets block-device tunings on startup

2011-11-02 Thread Michael Biebl
Am 02.11.2011 15:47, schrieb Alexander Kurtz: tags 625606 security thanks Hi, this bug introduces a new security hole, consider the following example: # cat /etc/fstab [...] /home /mnt none bind 0 0 /home /mnt none bind,remount,ro 0 0 # mount -v -a

Bug#625606: upower: resets block-device tunings on startup

2011-11-02 Thread Yves-Alexis Perez
On mer., 2011-11-02 at 15:47 +0100, Alexander Kurtz wrote: Notice how calling pm-powersave changes the mount options from read-only to read-write. Since I'm actually using something like this on a server to deliver read-only backups, this bug is quite serious for me. The actual problem here is

Bug#625606: upower: resets block-device tunings on startup

2011-11-02 Thread Alexander Kurtz
On Wed, 2011-11-02 at 15:57 +0100, Michael Biebl wrote: Isn't that rather a bug in mount, if it changes ro to rw? It's not like pm-utils uses mount -o remount,rw. No, it's actually a bug in how mount is used, mount(8) says: The remount functionality follows the standard way how the

Bug#625606: upower: resets block-device tunings on startup

2011-10-30 Thread Alexander Kurtz
# Justification: Breaks unrelated software (see below) severity 625606 critical thanks On Mon, 2011-05-30 at 00:01 +0200, Mario 'BitKoenig' Holbe wrote: Everything of this may interfer with tunings applied by users or other packages and nothing in the pm-utils package description does even

Bug#625606: upower: resets block-device tunings on startup

2011-10-30 Thread Alexander Kurtz
On Sun, 2011-10-30 at 19:09 +0100, Alexander Kurtz wrote: The end result is that the network card which actually should respond to every kind of WOL-event (pumbg) only responds to Magic-Packet (g) while all the other cards which should respond to nothing actually respond to Magic-Packets. Not

Bug#625606: upower: resets block-device tunings on startup

2011-05-29 Thread Mario 'BitKoenig' Holbe
reassign 625606 pm-utils thanks On Wed, May 04, 2011 at 04:01:32PM +0200, Mario 'BitKoenig' Holbe wrote: upowerd resets or modifies block-device tuning parameters (like read-ahead) on start-up. This behaviour is nothing one would expect upowerd to do according to it's specification and it

Bug#625606: upower: resets block-device tunings on startup

2011-05-04 Thread Mario 'BitKoenig' Holbe
Package: upower Version: 0.9.9-4 Severity: important Hello, upowerd resets or modifies block-device tuning parameters (like read-ahead) on start-up. This behaviour is nothing one would expect upowerd to do according to it's specification and it does directly affect