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.
CC: (none) => marja11Assignee: bugsquad => guillomovitch
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.
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.
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.
(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-bugsSummary: 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 impossibleSource RPM: cryptmount => ??
CC: (none) => guillomovitch
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.
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
No reply, so closing as OLD since Mageia 5 is no longer maintained.
Resolution: (none) => OLDStatus: NEW => RESOLVED