NWlogin with pam_script (TID 3416680)

Following the old TID 3416680 for SLED10 I'm trying to set up nwlogin
with pam_script: use PAM_AUTHTOK within /etc/security/onauth to assign
the password of the user doing a (ssh) login to the variable NWpassword
and then using nwlogin with the option --passenv.
Then in /etc/security/onsessionopen the eDirectory login scripts are
called with nwrunscripts.
The problem I have to make this work is that pam_script runs in the
context of root. That is after doing a ssh login as an eDirectory user
effectively root is logged in to the tree and all mapped drives are
owned by root rather than by the user. I did some tests with "su -"
within the scripts but this easily creates a loop as su itself calls
pam_script. So I wonder how to make this work.

Günther
  • Günther Schwarz wrote:
    > Following the old TID 3416680 for SLED10 I'm trying to set up nwlogin
    > with pam_script: use PAM_AUTHTOK within /etc/security/onauth to assign
    > the password of the user doing a (ssh) login to the variable NWpassword
    > and then using nwlogin with the option --passenv.
    > Then in /etc/security/onsessionopen the eDirectory login scripts are
    > called with nwrunscripts.
    > The problem I have to make this work is that pam_script runs in the
    > context of root. That is after doing a ssh login as an eDirectory user
    > effectively root is logged in to the tree and all mapped drives are
    > owned by root rather than by the user. I did some tests with "su -"
    > within the scripts but this easily creates a loop as su itself calls
    > pam_script. So I wonder how to make this work.


    OK, I gave up and went back to libpam-script-0.1.12 instead of
    pam-script-1.1.6. The older version runs within the user's context by
    default and thus does indeed work as described in in TID 3416680.
    Unfortunately an option "runas" which is readily available in version
    0.1.12 is missing in 1.1.6.
    If anybody wants to verify this: use "expose=authtok" within the auth
    part of pam in version 0.1.12 instead of "expose=1" for version 0.1.10
    which is used in the TID. Otherwise they seem to behave much the same.

    Günther

  • Hi Gunther,

    Perhaps post your question in the forums dedicated to SLED found here: https://forums.suse.com/forumdisplay.php?11-SLED-Configure-Administer

    You may get quicker results.

    Cheers,
  • laurabuckley wrote:

    > Perhaps post your question in the forums dedicated to SLED found here:
    > https://forums.suse.com/forumdisplay.php?11-SLED-Configure-Administer
    >
    > You may get quicker results.


    You might be right, though it is my impression that not too many people
    follow the discussions in SLED. I'll cross post anyway.
    Strictly speaking it was a question for OES as I have to do some
    administrative tasks on my servers that require a Novell login done via
    nwlogin as packed in novell-qtgui-cli. Thus the Novell Client that comes
    with SLED is not installed.
    Anyway, my problem is solved with using libpam-script-0.1.12 instead of
    pam-script-1.1.6 which results in running the nwlogin and nwrunscripts
    commands within the user context instead of root.

    Günther
  • Hi,

    I'm glad that you have it sorted. Thanks for posting back.

    Cheers,
  • Günther Schwarz wrote:
    > laurabuckley wrote:
    >
    >> Perhaps post your question in the forums dedicated to SLED found here:
    >> https://forums.suse.com/forumdisplay.php?11-SLED-Configure-Administer
    >>
    >> You may get quicker results.


    > Anyway, my problem is solved with using libpam-script-0.1.12 instead of
    > pam-script-1.1.6 which results in running the nwlogin and nwrunscripts
    > commands within the user context instead of root.


    It turn out I was too optimistic about this. It actually works as
    described in TID 3416680 for a console login, but not for ssh. With ssh
    I can't do the nwlogin within the auth part. Different environment for
    ssh as compared to a local login?
    As a workaround I can store the password within onauth somewhere and
    read it back within onsessionopen, doing the nwlogin there. This seems
    to be fine, but is kind of dirty. Any other suggestions?

    Günther

  • mikewillis wrote:
    >
    > =?UTF-8?B?R8O8bnRoZXIgU2Nod2Fyeg==?=;16959 Wrote:
    >> Günther Schwarz wrote:
    >> It turn out I was too optimistic about this. It actually works as
    >> described in TID 3416680 for a console login, but not for ssh. With ssh
    >> I can't do the nwlogin within the auth part. Different environment for
    >> ssh as compared to a local login?
    >>

    >
    > When you say you can't do nwlogin within the auth part, does that mean
    > you added the relevant lines to /etc/pam.d/sshd but it doesn't work?
    >
    > Something I've found helpful when debugging scripts being called by PAM
    > modules is to add lines like
    >
    > Code:
    > --------------------
    > debugfile="/tmp/$(basename $0)";
    > > "${debugfile}";

    > env > "${debugfile}";
    > --------------------
    >
    > so I can see what various variables are being set to. (Obviously
    > remember to remove that before production!)


    Yes, that helped a lot: Actually it turn out that nwlogin does need the
    HOME variable to be set. This is available upon login on a terminal but
    not in the auth section of a ssh login. So an

    export HOME=`/usr/bin/getent passwd $USER | /usr/bin/cut -d: -f6`

    within the onauth script solved my problem. Thank you very much in indeed.

    > On a tangential note I'm curious as to why the TID describes using
    > pam_script which is not included in SLED rather than pam_exec which is
    > included in SLED. I used to use pam_script to do some things at login
    > because that was a solution I found via Google and I was completely
    > ignorant of pam_exec. When I discovered pam_exec I switched to using
    > that. I had to tweak my scripts a bit but it does what I wanted to do as
    > well as pam_script did.


    Maybe pam_exec is simply less known. I was also not aware of it, so
    thanks for the hint. A quick first try shows that the scripts will
    indeed need some tweaks as

    auth optional pam_exec.so debug expose_authtok seteuid \
    /etc/security/onauth

    is not a plugin replacement for

    auth optional pam_script.so expose=authtok

    Günther