ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I wrote an authentication PAM module in C++, as I didn't want to deal with C for a few reasons, so I would prefer not having to re-write the entire module if possible.
I can compile the C++ code just fine, and have no issues running the ld command, but when I try to test the module using pamtester, I get an error message saying:
[quote]pamtester: Module is unknown[/code]
I dug into /var/log/auth.log (as faillog has no information), and found these entries:
Nov 5 01:22:41 localhost pamtester: PAM unable to dlopen(/lib/security/pam_zorpher.so): /lib/security/pam_zorpher.so
Nov 5 01:22:41 localhost pamtester: PAM adding faulty module: /lib/security/pam_zorpher.so
I would start by using the ldd command to see what your .so file depends on.
I have no idea what rules and limits apply to PAM modules. But I doubt NevemTeve's answer (that you must code it in C) is correct.
Whatever call points your .so exports should be declared
otherwise, a client expecting a C .so can't use your C++ .so. But that doesn't require you to rewrite in C. A C++ function declared extern "C" is still a C++ function, it is just called using C calling and naming standards. This (extern C) is probably the important part of the answer, but I don't know enough about PAM modules to give you specifics.
It is possible you will need to link some C++ library code from .a files rather than .so files. I really don't know enough about PAM modules to give you any details about that.
I need to use -fPIC because of it being a shared library (If I don't make it shared I either get a lot of undefined symbol errors, or "relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC"). But, I still can't access the module. What I did now is run ldd on the module:
I don't see how I could be having this issue compiling on a 64-bit system. I did read that using classes could cause a problem when it comes to extern "C", but not sure if that's the issue...and my program heavily relies on classes.
I typed up all the above before trying something else. It seemed I forgot to include a specific C++ source file along with the compiler line, which was because I didn't know that file was needed. The module loads fine now, and am able to test it. Thanks everyone for the help, and it seems that the extern "C" was a big help on this as well!
Please remember mention in your documentation that using your PAM module will break early userspace for systems where /usr is a separate mount point, and that it may break PAM-aware native C programs.
This is because your PAM module, unlike normal PAM modules, has a dependency on /usr/lib/libstdc++. Not only is it only available after /usr has been mounted, but it is known to (occasionally) have symbol collisions with perfectly valid C programs. Weird crashes may occur in innocent C programs using PAM, thanks to your PAM module.
Normal PAM modules only depend on libraries under /lib or /lib64 which are part of the root mount, and therefore available to early userspace. They have also minimal dependencies. Certain modules, like pam_ldap (and similar), do have dependencies outside /lib, but that is generally acceptable because the modules will never work before /usr has been mounted and network connections are available anyway. Password checking modules also often depend on external libraries, but they are obviously not critical during early userspace.
I also wonder what idiot has installed libgcc_s.so.1 under /usr/lib in your system, and not /lib or /lib64 where it belongs. Having it under /usr (or anywhere other than the root partition) will mean programs relying on it will not work during early userspace. Perhaps your distribution requires /usr to be a part of the root mount, and will fail if it is a separate mount point? (Funny but sad, if so.)
The early userspace I refer to here means the time during which init scripts are being run, but /usr has not been mounted yet. It is not that rare to for example mount /usr over the network. In fact, it is a very efficient solution if you have a lot of identical lightweight workstations (almost thin clients), good network infrastructure (GbE or better), and a powerful file server. (On many storage devices, I/O to small files is often slow unless already cached. Two thirds of files in my /usr/lib, /usr/bin, and /usr/sbin are under 16384 bytes. This means that /usr over NFS, with a good NFS server, is surprisingly snappy over GbE.)
For the above reasons, I think it is utterly inconsiderate (and, to be honest, stupid) to write a PAM library in C++. There is about zero chance of having it included in any major distribution. C++ is simply not a suitable language for PAM modules.
I apologise if my tone sounds harsh. It is just that there are repercussions to the choice of language (or, to be more specific, the library dependencies), which in the case of PAM modules are both complex and dangerous. In my opinion, certainly serious enough to override any personal preferences.