On 10/17/2011 04:39 PM, .. ink .. wrote: > Why doesnt cryptsetup support two factor authentication? I like the Unix approach - one simple program, one function. cryptsetup is nothing more than low-level configuration for dmcrypt and on-disk metadata (key management) wrapper. And provides library covering that. You can build various plugins (see e.g. how pam_mount or systemd uses libcryptsetup) but I would like to cryptsetup remains simple utility just for this exact task. (But maybe we should add various wrappers to code tree later.) > That is why i started this project with two requirements, it has to > work without requiring root's password(suid program) and it must > work with encrypted files, of type "plain" because thats what we have > mostly. It already does what i want, i am working on it further to > learn more and make cryptsetup easier to use for others too. That's fine. Just now it is time to do it properly if you want others to use it;-) > Can you clarify on this? it will not work because dlopen isnt > present/works differently in 64 bit or because the search path in my > code does not include /lib64? Just use it as shared library and use libcryptsetup.h, see for example docs/examples in cryptsetup source tree. (Btw if you need more examples, just tell me, we can add something there for reference.) > but why you are doing this at all? There are versioned symbols, you > should link the program directly to library... (Otherwise after > upgrade in future this can do really bad things.) > > > because this is my first attempt at meaning programming and i am > creating an suid program without really comprehending a lot of what i > am doing and suid program in linux are practically considered a sin, > was just trying to cover my bases by being as specific as i can. I > though going straight and manually picking a library will be more > secure. Will go back to linking directly. Thanks for the input. Currently libcryptsetup is designed to run root-only. (The main reason is that device-mapper in kernel require root capability for all operations. I hope this will change in future and user will be able to create private devices without requiring root privilege - but we are not there yet.) > I could have statically link against the library but pclinuxos does > not ship with the static library, cryptsetup only build it on > request at build time and i though other distros also do not ship > with the static library and this could inconvenience users and thats > why i went with the shared library. Avoid static libraries if possible. (If done properly, it can be more secure but usually it is security disaster - usually nobody cares about properly rebuilding all dependencies if problem is found. Most of recent generic distros are using dynamic libraries only.) Or better (but I think it is not good idea for GUI) - provide option to link statically. > While we are talking about cleaning the code, from what i know so > far, "mount/umount" system calls do not add entries in "/etc/mtab" > and tools like kdiskfree do not show these opened volumes if they do > not have entries in mtab, manually editing the file corrupts it and > that is why i use "mount/umount" cli tools through popen because they > do whatever they to do add entries in mtab on mounting and unmounting > volumes. /etc/mtab is on many systems just link to /proc/mounts, you cannot edit it directly. What exactly you are trying to do? mount/kernel should handle this file. And mounted fs is not the only possible user of LUKS volume, you can have mapped LVM volumes over it, MD raid, loopback, partition, .... Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
