dm_init_context should uid-0 restriction applies ?

[GoogleCodeExporter]

AFAICT the only privileged operation needed for luksOpen to succeed is the loop 
creation.

Considering that :
1) cryptmount is able to assign the unprivileged group of the invoking user to 
the newly created device mapper (at the cost of a bunch of suid lines).
2) in some distribution, there are plan to assign /dev/loop-control to the 
"disk" group [1]
3) unprivileged loop-mounted encrypted-(regular)-file is very useful in many 
use-cases

Could it be possible to amend (remove ?) the
> if (getuid() || geteuid())
call in dm_init_context()  [ lib/libdevmapper.c ]

Of course, if loop-control is root:root owned, a failure would arises since 
cryptsetup isn't suid but that would be helpful in setup using another 
permission-scheme.

Obviously, in order to do an unprivileged mount of this device mapper, 
/etc/fstab and/or other mechanisms needs to be used but this is out of the 
scope of cryptsetup.

Then come the question of closing (and other operation).

1) - setting owernship the newly created device solves all the questions of the 
other operations which apply on a given /dev/mapper file and will respect file 
permission
- *but* needs a couple of lines running suid to do that (could be a 2-lines 
wrapper simply firing an ioctl to loop-control to get a new free loop)

2) Otherwise cryptsetup could try to ensure the device on which 
Close/Suspend/Whatever is to be applied is *really* belonging to the initial 
user who previously luksOpen'ed.
But since losetup would just attribute every new nodes to root:disk, it seems 
more tricky. (More exactly, it would probably need to keep yet another 
/run/state-file that no-one wants)

Any advice in the direction of such a root less-dependant crypt setup 
appreciated.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1045432

Original issue reported on code.google.com by raphael....@gmail.com on 10 Mar 2014 at 2:07

[GoogleCodeExporter]

> AFAICT the only privileged operation needed for luksOpen to succeed is the 
loop creation.

Unfortunately, this is not correct. The main problem is that device-mapper 
subsystem is configurable only by root (resp. to users with CAP_SYSADMIN 
privilege).

With current implementation we need temporary dmcrypt device even for LUKS 
keyslot manipulation (and obviously for activation/deactivation of device).

Loop device is just side issue...

We tried to solve this long time ago by implementing "private" device-mapper 
devices, some test patches were written but abandoned.

See http://permalink.gmane.org/gmane.linux.kernel.device-mapper.devel/15649

"cryptmount" does this simply by using suid binary (so the DM code run as root 
eid).

In theory, I can reimplement LUKS handling to use kernel crypto API interface 
(available for user) - similarly to TrueCrypt compatible support but I am not 
able to activate/deactivate device without root privilege or additional patches.

Assigning some user available group as owner of device is a side problem and I 
think it is already doable as udev rule (I think Ondra had patches for these 
together with RFC patches).

But the real problem is mentioned above - device-mapper subsystem need to allow 
non-root to create device, without it we cannot do anything...

(Anyway, read the dm-devel discussion mentioned above - it was intended to 
solve _exactly_ the situation you are describing. I would be happy if anyone 
revive this and the patches are merged to kernel.)
After this is done, I can implement all needed things inside userspace 
cryptsetup. But for now, it is impossible without kernel changes.

Original comment by gmazyl...@gmail.com on 10 Mar 2014 at 8:19

• Changed state: Done