Bug 18735

Summary: When cryptmount brings up a new encrypted object, somethng demands to mount the /dev/dm-? file created, which is impossible
Product: Mageia Reporter: w unruh <unruh>
Component: RPM PackagesAssignee: All Packagers <pkg-bugs>
Status: RESOLVED OLD QA Contact:
Severity: minor    
Priority: Normal CC: guillomovitch, marja11
Version: 5   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: ?? CVE:
Status comment:

Description w unruh 2016-06-18 18:56:59 CEST
Description of problem:

Set up cryptmount to use a file as an encrypted container whose contents are to be mounted on /usr/crypt. 
It all works fine, except that something (udev?) sees the new /dev/dm-* file and 
brings up Mageia's system to mount /dev/dm-* somewhere (/run/media/....?)
Since I am using cryptmount as a user, this brings up the window asking for a password to be able to run the priviledged mount and hijacks the focus so that anything typed goes in as the password. (If I am doing cryptmount -a so I am mounting a number of containers, this can make things really annoying).
When I cancel that password window, everything works just fine (except a popup from the lower icon tray comes up saying it is unable to mount the dm- device.)

Somehow one should be able to tell the system not to try to mount a new dm device.



Version-Release number of selected component (if applicable): cryptmount-5.0-4.1.mga5.src.rpm


How reproducible: Almost always-- with varying time delays.
Marja Van Waes 2016-06-19 16:12:53 CEST

CC: (none) => marja11
Assignee: bugsquad => guillomovitch

Comment 1 Guillaume Rousse 2016-07-04 20:06:27 CEST
I'd rather incriminate some automounter than cryptmount here, but I have no clue about which one... It was rather trendy to blame systemd for all kind of issues some times ago, but according to its documentation, it should only deals with /etc/crypttab content.
Comment 2 w unruh 2016-07-04 20:49:05 CEST
Almost certainly true. I suspect that udev suddenly sees the /dev/dm-1 file, and says "I have to mount that in the /run heirarchy." 
/usr/lib/rules.d/10-dm?
(I cannot figure out what goes on in there)
I also suspect that the program cryptmount has nothing to do with it, but since running it is the proximate cause and I have no idea what the real cause is, I posted this as a cryptmount bug.
Comment 3 w unruh 2016-07-24 03:10:38 CEST
It is clear that what is happening is the cryptmount creates a /dev/dm-? device, and something (udev probably) notices this and tries to mount that dm file onto /run/media/<username/... Even if I enter the correct password, the mount attempt always fails. Sometimes it tries the mount on its own, and fails.

Since cryptmount is suid, and thus can be run by a user, udev asks (sometimes-- it is flakey ) to mount that device which it needs to be root to do.
But I hav3e no idea where in udev this would all take place.
Comment 4 Marja Van Waes 2016-07-24 08:16:55 CEST
(In reply to Guillaume Rousse from comment #1)
> I'd rather incriminate some automounter than cryptmount here, but I have no
> clue about which one... It was rather trendy to blame systemd for all kind
> of issues some times ago, but according to its documentation, it should only
> deals with /etc/crypttab content.

Re-assigning to all packagers collectively, in the hope that someone will find the real culprit.

Assignee: guillomovitch => pkg-bugs
Summary: When cryptmount brings up a new encrypted object, somethng demands to mount the /dev/dm-? file created => When cryptmount brings up a new encrypted object, somethng demands to mount the /dev/dm-? file created, which is impossible
Source RPM: cryptmount => ??

Marja Van Waes 2016-07-24 08:17:44 CEST

CC: (none) => guillomovitch

Comment 5 w unruh 2016-07-28 17:37:31 CEST
Just a bit more information: 
The window comes up saying 
Authenticatio is required to mount /dev/dm-1
Under more details:
Action: Mount a filesystem on a system device
Vendor: The udisks Project
polkit.subject-pid: 2163
polkit.caller-pid: 2196

Those pids are

planet[unruh]>psg 2163
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
unruh     2163  0.0  0.5 1185680 21588 ?       Sl   Jun27   0:14 kdeinit4: kded4 [kdeinit]
planet[unruh]>psg 2196
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      2196  0.0  0.0 492384  3368 ?        Ssl  Jun27   0:55 /usr/lib/udisks2/udisksd --no-debug


Hope this helps figure out what it is that is trying to mount these /dev/dm devices.
Comment 6 Marja Van Waes 2018-04-25 13:37:37 CEST
Hi w unruh,

Thank you for having taken the needed time to report this issue!

Did this bug get fixed? If so, please change its status to RESOLVED - FIXED

If it didn't, then we regret that we weren't able to fix it in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/
It only continued to get important security updates since then, because we are waiting for a big Plasma5 update in Mageia 6, that'll fix many of the Mageia 5 => 6 upgrade issues.

If you haven't seen that this bug got fixed, then please check whether this bug still exists in Mageia 6. If it does, then please change the Version (near the top, at the left) to "6". If you know it exists in Cauldron, then change Version to Cauldron. If you see it in both Cauldron and Mageia 6, then please set Version to Cauldron and add MGA6TOO on the Whiteboard.

Thanks,
Marja
Comment 7 Marja Van Waes 2018-10-07 16:00:14 CEST
No reply, so closing as OLD since Mageia 5 is no longer maintained.

Resolution: (none) => OLD
Status: NEW => RESOLVED