Bug#901062: qtbase5-dev: qtbase5-dev: QFile::exists() returns false for existing files?!

[Wearenotalone]

Found the bug.

Docker uses seccomp security profiles to restrict e.g. system calls [1].
In docker 17.05 system call "statx" is blocked [2][3], in trunk and in
18.04 which is not released yet that system call will be allowed [4][5].
By running the docker container with "--security-opt seccomp=unconfined"
or "--privileged" the system call "statx" not blocked [5] and everything
works as excepted: QFile::exists() returns true for existing files.

Older revisions of QFile (e.g. qt 5.7 from debian stretch) do work as
excepted even when statx is blocked, because they do not use system call
"statx".

That system call is not necessary to find out if a file exists. Qt is
able to detect whether "statx" is supported. But it fails to detect that
its call is not permitted. The reason for that is in
src/corelib/io/qfilesystemengine_unix.cpp which is still present in
latest upstream revision [6]. But lets start from the beginning:

QFile::exists() returns true if ExistsFlag is set [7]. Attributes are
set in "QFSFileEnginePrivate::doStat" [10]. This function first reads
attributes with 2-args-function-overload
"QFileSystemEngine::fillMetaData" [11] and then loads the missing
attributes with 3-args-function-overload
"QFileSystemEngine::fillMetaData" [12]. Boths overloads suffer from the
same bug.

The 2-args-overload "bool QFileSystemEngine::fillMetaData(int fd,
QFileSystemMetaData )" [11] calls "qt_fstatx". QtCore in debian sid
was build with a kernel that supports the statx system call and thus
function "qt_fstatx" does indeed call "syscall(SYS_statx, ...)". If this
syscall is blocked, then "syscall(...)" returns -1 and errno is set to 1
(EPERM == "Operation not permitted") [13]. Back in
"QFileSystemEngine::fillMetaData" [11] look at this code snippet:

  int ret = qt_fstatx(fd, );
  if (ret != -ENOSYS) {
  if (ret == 0) {
  data.fillFromStatxBuf(statxBuffer);
  return true;
  }
  return false;
  }

If statx is blocked, then ret==-EPERM (negated in [14]), which means
"return false" is executed, thus no attributes are read.

"QFSFileEnginePrivate::doStat" now executes the 3-args-overload "bool
QFileSystemEngine::fillMetaData(const QFileSystemEntry ,
QFileSystemMetaData , QFileSystemMetaData::MetaDataFlags what)"
[12]. It contains this snippet:

  statResult = qt_lstatx(nativeFilePath, );
  if (statResult == -ENOSYS) {
  //...
  } else if (statResult == 0) {
  //...
  }
 
  if (statResult >= 0) {
  //...
  } else {
  // it doesn't exist
  entryErrno = errno;
  data.knownFlagsMask |= QFileSystemMetaData::ExistsAttribute;
  }

When statx is blocked then statResult is -1 (-EPERM) and thus last
branch is executed. Thus 3-args-overload of fillMetaData says "i know
that file does not exist" (knownFlagsMask has ExistsAttribute but
entryFlags has not). The code "data.entryFlags |= flag |
QFileSystemMetaData::ExistsAttribute;" later in that function [16] is
never executed because entryErrno equals -1 (-EPERM).

Thus QFile always returns false, for all files, even existing once, as
long as statx is supported but blocked via e.g. seccomp.

Cheers,
Jakob


[1] https://github.com/Microsoft/docker/blob/master/docs/security/seccomp.md
[2] debian package "docker-engine" currently available for stretch is
17.05.0~ce-0~debian-stretch
[3] https://github.com/moby/moby/blob/17.05.x/profiles/seccomp/default.json
[4] https://github.com/moby/moby/blob/master/profiles/seccomp/default.json
[5] https://github.com/docker/for-linux/issues/208
[6]
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp
[7] https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfile.cpp#n425
[8] -DELETED-
[9] -DELETED-
[10]
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfsfileengine_unix.cpp#n419
[11]
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp#n439
[12]
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp#n931
[13] /usr/include/asm-generic/errno-base.h
[14]
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp#n350
[15]
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp#n979
[16]
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp#n1053

Am 08.06.2018 um 20:54 schrieb Dmitry Shachnev:
> Hi Jakob!
>
> On Fri, Jun 08, 2018 at 04:01:54PM +0200, Wearenotalone wrote:
>> did a fresh install of debian sid within docker and stumbled upon this
>> bug in QFile:
>> QFile's method exists() returns false even if that file exists.
> Thanks for your bug report and the test case.
>
> Can you please obtain strace of your example and attach it?
> I am not able to reproduce this issue, but I would like to compare yours
> and mine strace outputs.
>
> --
> Dmitry Shachnev

Bug#901062: qtbase5-dev: qtbase5-dev: QFile::exists() returns false for existing files?!

[Wearenotalone]

Package: qtbase5-dev
Version: 5.10.1+dfsg-7
Severity: normal


Dear Maintainer,
 
did a fresh install of debian sid within docker and stumbled upon this
bug in QFile:
QFile's method exists() returns false even if that file exists.



STEPS TO REPRODUCE:

$ cat << 'EOF' >> /tmp/CMakeLists.txt
cmake_minimum_required(VERSION 3.0)

project(test)

find_package(Qt5Core REQUIRED)

add_executable(tgt main.cpp)

target_link_libraries(tgt Qt5::Core)
EOF

$ cat << 'EOF' >> /tmp/main.cpp
#include 
#include 
#include 
#include 

int main() {
    QString path{"/bin/sh"};
    QFile qf{path};
    QFileInfo qfi{path};
    std::cout << "TRUE:=" << true << std::endl;
    std::cout << "QFile::exists() == " << qf.exists() << std::endl;
    std::cout << "QFileInfo::exists() == " << qfi.exists() << std::endl;
    return 0;
}
EOF

$ cmake .
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/

$ make
Scanning dependencies of target tgt
[ 50%] Building CXX object CMakeFiles/tgt.dir/main.cpp.o
[100%] Linking CXX executable tgt
[100%] Built target tgt

$ ./tgt
TRUE:=1
QFile::exists() == 0
QFileInfo::exists() == 1



EXPECTED RESULT (same as in debian stretch):

$ ./tgt
TRUE:=1
QFile::exists() == 1
QFileInfo::exists() == 1



QFile is quite fundamental to Qt and KDE. For me it prevented
compilation of kdevelop from git because kdevelop uses desktoptojson
(from libkf5coreaddons-dev-bin) during build which fails due to this bug
(QFile is used in line 312 in file
kcoreaddons-5.46.0/src/lib/plugin/desktopfileparser.cpp)..

So far I was unable to locate the bug. QFile's code
(src/corelib/io/qfile.cpp) didn't change much from
qtbase-opensource-src-5.7.1 (stretch) to qtbase-opensource-src-5.10.1
(sid), so my guess is its somewhere in
/src/corelib/io/qabstractfileengine.cpp or even lower.

BUT surprisingly KDE apps like akregator have successfully been build
for debian sid but fail for me/my sid install. They should have suffered
the same problems during build because they also use desktoptojson
during build.

Any ideas?

Cheers
Jakob



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages qtbase5-dev depends on:
ii  libgl1-mesa-dev [libgl-dev]    18.0.5-1
ii  libglu1-mesa-dev [libglu-dev]  9.0.0-2.1
ii  libqt5concurrent5  5.10.1+dfsg-7
ii  libqt5core5a   5.10.1+dfsg-7
ii  libqt5dbus5    5.10.1+dfsg-7
ii  libqt5gui5 5.10.1+dfsg-7
ii  libqt5network5 5.10.1+dfsg-7
ii  libqt5printsupport5    5.10.1+dfsg-7
ii  libqt5sql5 5.10.1+dfsg-7
ii  libqt5test5    5.10.1+dfsg-7
ii  libqt5widgets5 5.10.1+dfsg-7
ii  libqt5xml5 5.10.1+dfsg-7
ii  libxext-dev    2:1.3.3-1+b2
ii  qt5-qmake  5.10.1+dfsg-7
ii  qtbase5-dev-tools  5.10.1+dfsg-7
ii  qtchooser  64-ga1b6736-5

Versions of packages qtbase5-dev recommends:
ii  libqt5opengl5-dev  5.10.1+dfsg-7

Versions of packages qtbase5-dev suggests:
ii  default-libmysqlclient-dev  1.0.4
pn  firebird-dev    
ii  libegl1-mesa-dev    18.0.5-1
ii  libgl1-mesa-dev 18.0.5-1
ii  libpq-dev   10.4-2
ii  libsqlite3-dev  3.23.1-1
ii  unixodbc-dev    2.3.6-0.1

-- no debconf information

Bug#718348: closed by Lisandro Damián Nicanor Pérez Meyer lisan...@debian.org (Bug#718348: fixed in qtbase-opensource-src 5.1.0+dfsg-2)

[Wearenotalone]

Thank you!

Am 09.08.2013 05:21, schrieb Debian Bug Tracking System:

This is an automatic notification regarding your Bug report
which was filed against the qtbase5-dev package:

#718348: qtbase5-dev: Unable to configure cmake project using qt5 without 
qtbase5-private-dev

It has been closed by Lisandro Damián Nicanor Pérez Meyer lisan...@debian.org.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Lisandro Damián Nicanor Pérez 
Meyer lisan...@debian.org by
replying to this email.





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#668274: linux-image-3.2.0-2-amd64: Intel Core i3-2310M (HD 3000) / i915: Black screen at boot

[WEARENOTALONE]

Package: linux-2.6
Version: 3.2.14-1
Severity: normal

Dear Maintainers,
when I try to boot the current kernel 3.2 from debian wheezy||sid, my notebook 
screen goes black. Switching to another tty doesn't help, but the system is 
still usable e.g. via ssh. This bug is already known and fixed upstream (see 
[1] and [2]). Nevertheless, I report the bug here to track it and make sure it 
gets fixed for Debian Wheezy (as proposed by [3]).

My System: 
Lenovo Thinkpad L420
Intel Core i3-2310M
Linux 3.2.0-2-amd64 #1 SMP x86_64 GNU/Linux

Kind regards,
Jakob

[1] http://lists.freedesktop.org/archives/intel-gfx/2012-January/014332.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660394#85
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660394#80

-- Package-specific info:
** Version:
Linux version 3.2.0-2-amd64 (Debian 3.2.14-1) (debian-ker...@lists.debian.org) 
(gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Fri Apr 6 05:01:55 UTC 2012

** Command line:
BOOT_IMAGE=/vmlinuz-3.2.0-2-amd64 ro quiet selinux=0 apparmor=1 
security=apparmor i915.modeset=0

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[   14.516607] iwlwifi :03:00.0: Detected Intel(R) Centrino(R) Wireless-N 
1000 BGN, REV=0x6C
[   14.516674] iwlwifi :03:00.0: L1 Disabled; Enabling L0S
[   14.520587] snd_hda_intel :00:1b.0: PCI INT A - GSI 22 (level, low) - 
IRQ 22
[   14.520646] snd_hda_intel :00:1b.0: irq 43 for MSI/MSI-X
[   14.520672] snd_hda_intel :00:1b.0: setting latency timer to 64
[   14.536796] iwlwifi :03:00.0: device EEPROM VER=0x15d, CALIB=0x6
[   14.536799] iwlwifi :03:00.0: Device SKU: 0X50
[   14.536802] iwlwifi :03:00.0: Valid Tx ant: 0X1, Valid Rx ant: 0X3
[   14.536814] iwlwifi :03:00.0: Tunable channels: 13 802.11bg, 0 802.11a 
channels
[   14.585034] pci :00:02.0: irq 44 for MSI/MSI-X
[   14.585041] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   14.585044] [drm] No driver support for vblank timestamp query.
[   14.598449] iwlwifi :03:00.0: loaded firmware version 39.31.5.1 build 
35138
[   14.598592] Registered led device: phy0-led
[   14.606056] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[   14.610787] ACPI Warning: _BQC returned an invalid level (20110623/video-472)
[   14.612187] acpi device:38: registered as cooling_device4
[   14.612507] input: Video Bus as 
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input8
[   14.612567] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   14.612648] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[   14.641509] cfg80211: World regulatory domain updated:
[   14.641513] cfg80211: (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp)
[   14.641516] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[   14.641519] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[   14.641522] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[   14.641524] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[   14.641527] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[   15.081582] HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
[   15.081750] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0
[   15.081916] HDMI status: Codec=3 Pin=7 Presence_Detect=0 ELD_Valid=0
[   15.082100] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1b.0/sound/card0/input9
[   15.082201] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1b.0/sound/card0/input10
[   15.082292] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1b.0/sound/card0/input11
[   15.082567] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input12
[   15.082650] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input13
[   15.168842] psmouse serio4: synaptics: Touchpad model: 1, fw: 7.2, id: 
0x1c0b1, caps: 0xd047b3/0xb4/0xa
[   15.168862] psmouse serio4: synaptics: serio: Synaptics pass-through port at 
isa0060/serio4/input0
[   15.215410] input: SynPS/2 Synaptics TouchPad as 
/devices/platform/i8042/serio4/input/input14
[   15.325479] mdadm: sending ioctl 800c0910 to a partition!
[   15.325486] mdadm: sending ioctl 1261 to a partition!
[   15.325758] mdadm: sending ioctl 1261 to a partition!
[   15.325864] mdadm: sending ioctl 1261 to a partition!
[   15.326143] mdadm: sending ioctl 1261 to a partition!
[   15.326674] mdadm: sending ioctl 1261 to a partition!
[   15.326788] mdadm: sending ioctl 1261 to a partition!
[   15.327539] mdadm: sending ioctl 800c0910 to a partition!
[   15.327543] mdadm: sending ioctl 800c0910 to a partition!
[   15.432791] EXT4-fs (dm-2): re-mounted. Opts: (null)
[   15.441100] rts_pstor: device scan complete
[   15.441216] scsi 7:0:0:0: Direct-Access Generic- xD/SD/M.S.   

Bug#668274: Intel Core i3-2310M (HD 3000) / i915: Black screen at boot

[Wearenotalone]

Hello Jonathan,
... Am I correct in assuming 3.3 works fine on your machine? Cheers, 
Jonathan 
Yes, this bug seems to be fixed in linux-image-3.3.0-trunk-amd64 
(3.3-1~experimental.1).


Kind regards,
Jakob



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#660394: Screen goes blank @30 seconds into boot

[Wearenotalone]

Hello there,
after updating my Debian Wheezy/Testing to linux kernel 3.2 my screen 
goes black at boot, too. My system is a Lenovo Thinkpad L420 with an 
Intel Core i3 (HD3000) inside. The fix posted above 
(http://lists.freedesktop.org/archives/intel-gfx/2012-January/014332.html) 
fixes this bug for me.


If you dont want to compile a custom kernel, a temporary workaround is 
to add i915.modeset=0 to the grub command line.


Thank You!
WANA



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#660394: Screen goes blank @30 seconds into boot

[Wearenotalone]

Hi Jonathan,
my wording was a bit imprecise. My problem is already known upstream. So 
sooner or later the fix will make it into debian. I just wanted to let 
you know, that the patch and instructions you proposed are working for 
me. Thank you for that!


First i booted into my system by using the i915.modeset=0 workaround. 
Then i patched my kernel as proposed at [1], rebooted and voilà the 
black/blank screen is gone.


Kind regards

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660394#10

Am 07.04.2012 15:52, schrieb Jonathan Nieder:

Hi,

Wearenotalone wrote:


after updating my Debian Wheezy/Testing to linux kernel 3.2 my
screen goes black at boot, too. My system is a Lenovo Thinkpad L420
with an Intel Core i3 (HD3000) inside. The fix posted above 
(http://lists.freedesktop.org/archives/intel-gfx/2012-January/014332.html)
fixes this bug for me.

Please file a separate bug.

Thanks,
Jonathan






--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#480728: Info received (keytouch-init: failed to set keycode)

[Wearenotalone]

I don't know why but for me this problem is gone (around one week ago).
My keycodes are back:

$ LANG=C sudo getkeycodes
Plain scancodes xx (hex) versus keycodes (dec)
for 1-83 (0x01-0x53) scancode equals keycode

 0x50:   80  81  82  83  84   0  86  87
 0x58:   88 117   0   0  95 183 184 185
 0x60:0   0   0   0   0   0   0   0
 0x68:0   0   0   0   0   0   0   0
 0x70:   93   0   0  89   0   0  85  91
 0x78:   90  92   0  94   0 124 121   0

Escaped scancodes e0 xx (hex)

e0 00:0   0   0   0   0   0   0   0
e0 08:0   0   0   0   0   0   0   0
e0 10:  165 216 212 148 221   0   0   0
e0 18:0 163   0   0  96  97   0   0
e0 20:  113 140 164   0 166   0   0   0
e0 28:0   0 255   0   0   0 114   0
e0 30:  115   0 172   0   0  98 255  99
e0 38:  100   0   0 144 202 159 173 131
e0 40:  129 210 203 157 145 119 119 102
e0 48:  103 104   0 105 112 106 118 107
e0 50:  108 109 110 111   0   0   0 169
e0 58:  213   0   0 125 126 127 116 142
e0 60:0   0   0 143   0 217 156 173
e0 68:  128 149 158 157 155 226   0 112
e0 70:0   0   0   0   0   0   0   0
e0 78:0   0   0   0   0   0   0   0

The only thing i did was updating my system (debian squeeze). Now
everything works just as usual again (including keytouch).



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#516003: (no subject)

[Wearenotalone]

Thanks for your feedback :)

But why is a loop device attached to my LUKS partition?



Because you specified so.

  
I already noticed that i made some bad configuration mistakes ;) But i 
don't know for sure, where exactly i made this error. Is my assumption 
correct, that this problem is caused by the keybits option (or by me, 
because i specified the keybits option)?


What suggestions do you have in order to fix this problem? Just ignore 
the keybits option?


I think that it is not nice to other users, to just ignore this. We 
should somehow warn the users (e.g. manpage or readme) to not use the 
keybits and encryption option together with LUKS partitions (if this is 
the reason for the umount error)...


Best Regards,
WANA



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#516003: (no subject)

[Wearenotalone]

Jan Engelhardt schrieb:

On Sunday 2009-03-01 18:19, Wearenotalone wrote:
  

Thanks for your feedback :)


But why is a loop device attached to my LUKS partition?


Because you specified so.
  

I already noticed that i made some bad configuration mistakes ;) But i don't
know for sure, where exactly i made this error. Is my assumption correct, that
this problem is caused by the keybits option (or by me, because i specified the
keybits option)?

What suggestions do you have in order to fix this problem? Just ignore the
keybits option?



For your specific problem, omit the loop option in the options=
in volume.

I do not think this has anything to do with the keybits option.

  
I never explicitly used the loop option, but even so a loop device 
(loop1) is mounted on top of my LUKS Partition. That's what surprised 
me! And thats why i suspect the keybits option. Please see e.g. Message 
30 for my mount options ( 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516003#30 ). But 
perhaps we're talking at crossed purposes...


Regards,
WANA



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#516003: segfault caused by umount.crypt after libpam-mount update

[Wearenotalone]

Hello,

Bastian Kleineidam schrieb:

Hi,

Am Friday 20 February 2009 11:50:48 schrieb Wearenotalone:
  

Yesterday i continued looking for a solution to my problem. At first i
changed my volume definition to

volume fskeycipher=aes-256-cbc fskeyhash=sha512
options=fsk_cipher=aes-256-cbc,fsk_hash=sha512,keyfile=/my/encrypted.key,f
sck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,has
h=sha512 fskeypath=/my/encrypted.key user=MYUSERNAME mountpoint=/mnt
path=/my/encrypted.img /

Was there a mount error without the changes? The options fsk_cipher and 
fsk_hash are duplicates of fskeycipher and fskeyhash, so I am wondering why 
you added them.


  
These entries are leftovers from my unsuccessful attempt to use the 
fsk_hash option with libpam_mount 0.44-1+lenny3. At the moment i use 
this config for version 1.9, 1.10 and 1.18:
volume fskeycipher=aes-256-cbc fskeyhash=sha512 
options=fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256 
fskeypath=/my/encrypted.key user=MYUSERNAME mountpoint=/mnt/tmp1 
path=/my/encrypted.img fstype=crypt /


With version libpam-mount 1.9 and the keybits=256 option set, i get a 
segfault everytime i log out. Without the keybits option, everything 
seems to be fine. With the newest libpam-mount 1.10 it is still the same.



After this unsatisfactory result i updated libpam-mount to version 1.18

Please test with official Debian packages, unless you want to take this 
problem to the official mailing list.
I will package libpam-mount  1.10 when there is a safe upgrade path for the 
new cmtab code (ie.a fallback to mtab).


  
Ok, i just wanted to inform you that the segfault is gone with the 
newest version. But even if this segfault is gone, the problems (unmount 
not successful / loop device on top of LUKS partition) still exist. For 
future tests i set up a VM with Debian so that i can test different 
libpam-mount packages without risking data loss. The previously 
mentioned tests in this mail (libpam-mount 1.9 and 1.10) were carried 
out in this VM (got the same results with my regular system before).

But why is a loop device attached to my LUKS partition? Is it not enough
if only the LUKS partition is mounted and not another loop device on top
of it?


What is your exact setup after mounting? I assume the following

/my/encrypted.img  (loop)
  /dev/loop0  (luks)
  /dev/mapper/_my_enrypted_img  (loop)
  /dev/loop1

If this is the case, the second /dev/loop1 mount is indeed unneeded.

  

With keybits option and libpam-mount 1.10 ( before logout ):

$ losetup -a
/dev/loop0: [0801]:441553 (/my/encrypted.img)
/dev/loop1: [000d]:23903 (/dev/mapper/_my_encrypted_img)

$ mount | grep /my/encrypted.img
/my/encrypted.img on /mnt/tmp1 type crypt 
(keybits=256,noexec,nodev,nosuid,relatime)


$ cat /etc/mtab  | grep /my/encrypted.img
/my/encrypted.img /mnt/tmp1 crypt 
keybits=256,noexec,nodev,nosuid,relatime 0 0


$ tail -n 28 /var/log/all
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(pam_mount.c:312): 
pam_mount 1.10: entering auth stage
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_unix(login:session): session 
opened for user MYUSERNAME by LOGIN(uid=0)
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(pam_mount.c:458): 
pam_mount 1.10: entering session stage
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(pam_mount.c:479): back 
from global readconfig
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(pam_mount.c:481): 
per-user configurations not allowed by pam_mount.conf.xml
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(misc.c:38): Session 
open: (uid=0, euid=0, gid=1000, egid=1000)
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(rdconf2.c:182): 
checking sanity of volume record (/my/encrypted.img)
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(pam_mount.c:536): 
about to perform mount operations
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(mount.c:181): Mount 
info: globalconf, user=MYUSERNAME volume server=(null) 
path=/my/encrypted.img mountpoint=/mnt/tmp1 cipher=(null) 
fskeypath=/my/encrypted.key fskeycipher=aes-256-cbc 
fskeyhash=sha512 
options=keybits=256,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256 
/ fstab=0
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(mount-sysv.c:57): 
realpath of volume /mnt/tmp1 is /mnt/tmp1
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(mount-sysv.c:61): 
checking to see if /my/encrypted.img is already mounted at /mnt/tmp1
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(mount.c:494): checking 
for encrypted filesystem key configuration
Feb 24 18:09:34 MYHOSTNAME login[5707]: pam_mount(mount.c:497): about to 
start building mount command
Feb 24 18:09:34 MYHOSTNAME login[5707]: command: [mount.crypt] 
[-ofsk_cipher=aes-256-cbc] [-ofsk_hash=sha512] 
[-okeyfile=/my/encrypted.key] 
[-okeybits=256,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256] 
[/my/encrypted.img] [/mnt/tmp1]
Feb 24 18:09:34 MYHOSTNAME login[5723]: pam_mount(misc.c:38

Bug#516003: segfault caused by umount.crypt after libpam-mount update

[Wearenotalone]

): 
received order to close things
Feb 19 20:21:51 MYHOSTNAME login[4568]: pam_mount(misc.c:38): Session 
close: (uid=0, euid=0, gid=1000, egid=1000)
Feb 19 20:21:51 MYHOSTNAME login[4568]: command: [pmvarrun] [-u] 
[MYUSERNAME] [-o] [-1]
Feb 19 20:21:51 MYHOSTNAME login[4644]: pam_mount(misc.c:38): 
set_myuidpre: (uid=0, euid=0, gid=1000, egid=1000)
Feb 19 20:21:51 MYHOSTNAME login[4644]: pam_mount(misc.c:38): 
set_myuidpost: (uid=0, euid=0, gid=1000, egid=1000)
Feb 19 20:21:51 MYHOSTNAME login[4568]: pam_mount(pam_mount.c:418): 
pmvarrun says login count is 0
Feb 19 20:21:51 MYHOSTNAME login[4568]: pam_mount(mount.c:673): going to 
unmount
Feb 19 20:21:51 MYHOSTNAME login[4568]: pam_mount(mount.c:172): Mount 
info: globalconf, user=MYUSERNAME volume fstype=auto server=(null) 
path=/my/encrypted.img mountpoint=/mnt cipher=(null) 
fskeypath=/my/encrypted.key fskeycipher=aes-256-cbc 
fskeyhash=sha512 
options=fsk_cipher=aes-256-cbc,fsk_hash=sha512,keyfile=/my/encrypted.key,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,hash=sha512 
/ fstab=0

Feb 19 20:21:51 MYHOSTNAME login[4568]: command: [umount] [/mnt]
Feb 19 20:21:51 MYHOSTNAME login[4645]: pam_mount(misc.c:38): 
set_myuidpre: (uid=0, euid=0, gid=1000, egid=1000)
Feb 19 20:21:52 MYHOSTNAME login[4645]: pam_mount(misc.c:38): 
set_myuidpost: (uid=0, euid=0, gid=1000, egid=1000)
Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(mount.c:64): umount 
messages:
Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(mount.c:67): Command 
failed: Device busy
Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(mount.c:67): 
umount.crypt(crypto-dmc.c:160): Could not unload dm-crypt device 
/dev/mapper/_dev_loop0, cryptsetup returned HXproc status 240
Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(mount.c:67): umount: 
/mnt: not mounted
Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(mount.c:67): umount 
/mnt failed with run_sync status 1
Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(mount.c:67): Command 
failed: Device busy
Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(mount.c:67): 
umount.crypt(crypto-dmc.c:160): Could not unload dm-crypt device 
/dev/mapper/_dev_loop0, cryptsetup returned HXproc status 240
Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(mount.c:676): unmount 
of /my/encrypted.img failed
Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(pam_mount.c:633): 
pam_mount execution complete
Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(pam_mount.c:115): 
Clean global config (0)
Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(pam_mount.c:132): 
clean system authtok=0x8d68f58 (0)


The following is just pure speculation. I think the Command failed: 
Device busy is caused by int ehd_unload(const struct ehd_mount *mt) 
in crypto.c (umount.crypt / mount.crypt):


int ehd_unload(const struct ehd_mount *mt)
{
   int ret;

#if defined(__linux__)
   ret = ehd_dmcrypt_ops.unload(mt); //  WEARENOTALONE: Error???
#elif defined(HAVE_DEV_CGDVAR_H)
   ret = ehd_cgd_ops.unload(mt);
#endif

   /* Try to free loop device even if cryptsetup remove failed */
   if (mt-loop_device != NULL)
   ret = pmt_loop_release(mt-loop_device);

   return ret;
}

The function ehd_dmcrypt_ops.unload() fails because on top of my LUKS 
partition (/dev/mapper/_dev_loop0) a loop device is set up (/dev/loop1):


$ losetup -a
/dev/loop0: [0901]:14450726 (/my/encrypted.img)
/dev/loop1: [000d]:30967 (/dev/mapper/_dev_loop0)

That is why i have to do this manually:

losetup -d /dev/loop1
cryptsetup luksClose /dev/mapper/_my_encrypted_img
losetup -d /dev/loop0

But why is a loop device attached to my LUKS partition? Is it not enough 
if only the LUKS partition is mounted and not another loop device on top 
of it?


At the moment i am searching for the place in the sources where the 
(second) loop device (/dev/loop1) is attached to my LUKS partition. Do 
you have a hint where i could search?


Best Regards,
WEARENOTALONE



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#516003: segfault caused by umount.crypt after libpam-mount update

[Wearenotalone]

I think i have identified the cause of my unmount problem. The mount 
option keybits implies the loop option. This causes the LUKS partition 
again to be mounted as a loop device. At the moment mount.crypt only 
filters the loop option but not the keybits option.


Usualy this is no problem because the regular mount command writes the 
newly created loop device (the second one) to /etc/mtab (e.g. 
loop=/dev/loop1) and /proc/mounts. With the help of the -d option of 
umount the loop device is properly detached.


But at the moment mount.crypt (up from version 1.16) does not use 
/etc/mtab and /proc/mounts or at least is not able to detach the loop 
device. A simple insertion of umount_args[argk++] = -d; to the 
function mtcr_umount(...) in mtcrypt.c is not enough. The result of this 
shortcoming is that the LUKS partition is successfully unmounted but 
cannot be closed because there is still a open loop device left 
(/dev/loop1).


Because of that i can think of two solutions. The first one is to ignore 
the keybits option as we do with the loop option. The following patch 
for version 1.18 does this:


--- src/mtcrypt.c.old   2009-02-07 12:42:49.0 +0100
+++ src/mtcrypt.c   2009-02-20 18:28:23.0 +0100
@@ -158,6 +158,8 @@
   l0g(keysize mount option ignored\n);
   else if (strcmp(key, fsck) == 0)
   mo-fsck = true;
+   else if (strcmp(key, keybits) == 0)
+   l0g(keybits mount option ignored\n);
   else if (strcmp(key, loop) == 0)
   /* automatically detected anyway */
   l0g(loop mount option ignored\n);

The second way is to save any mount option to /etc/cmtab (in particular 
the loop=/dev/loop1 option) and then to properly detach the second loop 
device before luksClosing the LUKS partition. But this requires a little 
bit more work and should be done by someone with more linux and c 
development experience.


Of course the easiest solution would be not to use the keybits option at 
all. But nowhere is any hint that the user may not select this option, 
so nobody knows. Besides that i informed the developer of pam-mount 
(jengelh) about this bug report.


It would be very nice if someone could give me some feedback on this.

Best regards,
WANA



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#516003: segfault caused by umount.crypt after libpam-mount update

[Wearenotalone]

The first solution seems to be incomplete. If the keybits option is 
given then the loop device (/dev/loop1) on top of the LUKS partition is 
not created (correct behavior), BUT the loop device of the 
/my/encrypted.img file (/dev/loop0) is not removed after luksClosing 
/dev/mapper/_my_encrypted_img! The result of this is that at every login 
a new loop device is attached to the /my/encrypted.img but not removed 
after logout. Thats not nice. If you dont use the keybits option then 
everything is properly unmounted/luksClosed/detached.



While playing around with version 1.18 i also noticed that not specifing 
an keyfile option (not fskeypath=, but keyfile option in options=!) 
causes LUKS to drop this message:


pam_mount(mount.c:67): Command failed: No key available with this 
passphrase.


But i will investigate this later and probably open another bugreport.


Best Regards,
WANA



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org