Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
On Sun, Feb 05, 2012 at 10:51:08PM +0100, Petter Reinholdtsen wrote: > > [Andreas B. Mundt] > > How long? I think entering the username triggers autofs (to read the > > user's configuration, for example which desktop he want's to start by > > default). What if someone takes 15 seconds to enter his password, and > > someone else needs only 3 seconds? > > This do not sound right. Setups using pam_mount work, and I believe PAM > is only invoked after the password is entered. Because of this, I > believe the users home directory isn't accessed before the password is > entered. > I did not say that pam_mount doesn't work. I believe gdm tries to access the home directory. If it doesn't succeed, this is non-fatal. However we don't have to argue about that, it should be easy to check: Login on a terminal on a workstation as root, check if the home directories are not yet mounted and then login on gdm as a user and carefully check when the home directory is accessed/mounted using the terminal. > What are you seeing that make you believe PAM is invoked too late? > Could it be some other pam module called earlier in the stack that > causes the effect? Hm? Are we talking about the same issue, making a diskless workstation work without machine credentials? Best regards, Andi -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120206075235.GA4158@fuzi
Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
Hi On Sun, Feb 05, 2012 at 10:35:08PM +0100, Andreas B. Mundt wrote: > Hi, > > On Sun, Feb 05, 2012 at 05:25:20PM +0100, Giorgio Pioda wrote: > > > > The script executed right after authentication copies the user's > > > Kerberos ticket to the file krb5cc_diskless which is owned by root. > > > This ticket will be picked up by gssd to create the security context > > > needed. However, it's needed to restart autofs, I am not exactly sure > > > why. It looks like autofs caches failures in mounting a directory > > > (which it tries earlier in the login process), and does not try again > > > immediately when the ticket is available. > > > > > > > What about setting a delay in autofs? > > > > How long? I think entering the username triggers autofs (to read the > user's configuration, for example which desktop he want's to start by > default). What if someone takes 15 seconds to enter his password, and > someone else needs only 3 seconds? Only if exactly at the right > moment where pam gives the OK (i.e. the ticket is available) for login > the autofs is triggered it will manage to provide the home directory. > Imediatelly after that the user will have / as home (or might not be > allowed to login on gdm). It is pam that triggers autofs, I guess. Probably it is possible to construct pam rules in such a way that your script is first executed and only after this step aufofs is called, (either with libpam-script or libpam-exec). I've read around that such an hack has been tested for EduUbuntu (thiny client based), but the guys didn't publish the details. > So I don't think that will work. Did you have any success with the > >verify_ap_req_nofail = false > Yes, but it seems to be false by default. I have to test it again; no success until now. > stuff? > > Best regards, > > Andi > > > -- > To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/20120205213507.GA6821@flashgordon > > Regards Giorgio -- Sysadmin SPSE-Tenero Ufficio: +41 91 735 62 48 Cellulare: +41 79 629 20 63 -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120206074534.gb2...@ticino.com
Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
[Andreas B. Mundt] > How long? I think entering the username triggers autofs (to read the > user's configuration, for example which desktop he want's to start by > default). What if someone takes 15 seconds to enter his password, and > someone else needs only 3 seconds? This do not sound right. Setups using pam_mount work, and I believe PAM is only invoked after the password is entered. Because of this, I believe the users home directory isn't accessed before the password is entered. What are you seeing that make you believe PAM is invoked too late? Could it be some other pam module called earlier in the stack that causes the effect? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flk441kkz7@diskless.uio.no
Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
Hi, On Sun, Feb 05, 2012 at 05:25:20PM +0100, Giorgio Pioda wrote: > > The script executed right after authentication copies the user's > > Kerberos ticket to the file krb5cc_diskless which is owned by root. > > This ticket will be picked up by gssd to create the security context > > needed. However, it's needed to restart autofs, I am not exactly sure > > why. It looks like autofs caches failures in mounting a directory > > (which it tries earlier in the login process), and does not try again > > immediately when the ticket is available. > > > > What about setting a delay in autofs? > How long? I think entering the username triggers autofs (to read the user's configuration, for example which desktop he want's to start by default). What if someone takes 15 seconds to enter his password, and someone else needs only 3 seconds? Only if exactly at the right moment where pam gives the OK (i.e. the ticket is available) for login the autofs is triggered it will manage to provide the home directory. Imediatelly after that the user will have / as home (or might not be allowed to login on gdm). So I don't think that will work. Did you have any success with the verify_ap_req_nofail = false stuff? Best regards, Andi -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120205213507.GA6821@flashgordon
Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
Hi > > The script executed right after authentication copies the user's > Kerberos ticket to the file krb5cc_diskless which is owned by root. > This ticket will be picked up by gssd to create the security context > needed. However, it's needed to restart autofs, I am not exactly sure > why. It looks like autofs caches failures in mounting a directory > (which it tries earlier in the login process), and does not try again > immediately when the ticket is available. > What about setting a delay in autofs? -- Sysadmin SPSE-Tenero Ufficio: +41 91 735 62 48 Cellulare: +41 79 629 20 63 -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120205162520.ga2...@ticino.com
Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
Hi, On Fri, Jan 27, 2012 at 11:14:04PM +0100, Giorgio Pioda wrote: > > your solution seems more or less an unavoidable hack. > > Nice would be to tell Kerberos to avoid service check and control > only user ID. > > What about this: > > http://docs.oracle.com/cd/E19963-01/html/821-1456/setup-148.html#gihyu > > Maybe could be a solution, but I don't know exactly if it works > as I think it should: > > client # cat /etc/krb5/krb5.conf > [libdefaults] > default_realm = EXAMPLE.COM > verify_ap_req_nofail = false > ... I just tried with verify_ap_req_nofail = false and disabled the ticket copying, unfortunatelly it seems not to work here. I have to think about it, but isn't it necessary to have a ticket available as it is used to encrypt the connection to the NFS server (sec=krb5p)? Best regards, Andi -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120128094033.GA5120@flashgordon
Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
HI, your solution seems more or less an unavoidable hack. Nice would be to tell Kerberos to avoid service check and control only user ID. What about this: http://docs.oracle.com/cd/E19963-01/html/821-1456/setup-148.html#gihyu Maybe could be a solution, but I don't know exactly if it works as I think it should: client # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM verify_ap_req_nofail = false ... It should be possible to do it in a separate thiny client realm Cheers Giorgio On Fri, Jan 27, 2012 at 06:18:31PM +0100, Andreas B. Mundt wrote: > Hi Giorgio, > > On Fri, Jan 27, 2012 at 05:59:41PM +0100, Giorgio Pioda wrote: > > > > What does autofs manage? / or only /home0 ? > > > > Only home0 > > > > It shuldn't be that difficoult to mount / without kerberos > > with plain nfs mounting at boot time > > and /home0 with a securized env. later on login > > > > How to make the securized env. ? As far as I know for mounting NFSv4 > with sec=krb5 usually machine credential are needed > i.e. /etc/krb5.keytab. But /etc/krb5.keytab must not be in the > chroot, because it will be readable by everyone in the network. > > Do you know another solution to this problem? > > Cheers, > > Andi > > > > > On Fri, Jan 27, 2012 at 05:18:53PM +0100, Andreas B. Mundt wrote: > > > Hi everybody! > > > > > > Since quite some time we have been thinking about how to make > > > kerberized NFSv4 mounting of home directories work with diskless > > > clients, where no machine credentials (keytab) are available. > > > > > > It was mentioned [1] that using "-n" for gssd on the diskless client > > > might help, however this seems not to be enough. > > > > > > I finally figured out a way now, which works here and is not too > > > invasive: > > > > > > First, make sure you have the package libpam-script available at the > > > diskless client's chroot. libpam-script allows to run a script after > > > successfull authentication. The script executed can be created by > > > running: > > > > > > #!/bin/sh > > > # > > > set -e > > > > > > FILE=/usr/share/libpam-script/pam_script_auth > > > > > > cat > $FILE < > > #!/bin/sh > > > # > > > set -e > > > if [ \$PAM_USER = "root" ] || ls /tmp/krb5cc_diskless > /dev/null > > > 2>&1; then > > > exit 0 > > > fi > > > > > > FILE=/tmp/krb5cc_diskless > > > cp -v /tmp/krb5cc_pam_* \$FILE > > > /etc/init.d/autofs restart > /dev/null > > > > > > exit 0 > > > EOF > > > > > > chmod 0755 $FILE > > > # > > > > > > The script executed right after authentication copies the user's > > > Kerberos ticket to the file krb5cc_diskless which is owned by root. > > > This ticket will be picked up by gssd to create the security context > > > needed. However, it's needed to restart autofs, I am not exactly sure > > > why. It looks like autofs caches failures in mounting a directory > > > (which it tries earlier in the login process), and does not try again > > > immediately when the ticket is available. > > > > > > In addition, add the line > > >RPCGSSDOPTS="-n" > > > to /etc/default/nfs-common and the line > > >authoptional pam_script.so > > > to /etc/pam.d/common-auth. > > > > > > With these modifications fully kerberized NFSv4 mounting should > > > be possible on all machines if there are no other issues like those > > > reported in http://bugs.debian.org/613167#30> (pending?). I did > > > not test LTSP diskless clients but a home-made chroot in combination > > > with aufs. > > > > > > Best regards, > > > > > > Andi > > > > > > > > > [1] http://lists.debian.org/debian-edu/2010/07/msg00065.html > > > > > > > > > -- > > > To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org > > > with a subject of "unsubscribe". Trouble? Contact > > > listmas...@lists.debian.org > > > Archive: http://lists.debian.org/20120127161853.GA17722@flashgordon > > > > > > > > > > -- > > Sysadmin SPSE-Tenero > > Ufficio: +41 91 735 62 48 > > Cellulare: +41 79 629 20 63 > > -- > > -- > > A N D R E A S B. M U N D T > > Auf dem Rucken 68 > 89143 Blaubeuren > > > phone priv.: 0049 (0)7344 17 909 38 > mobile: 0049 (0)1577 29 222 42 >VoIP: sip:andi.mu...@ekiga.net > > email: andi.mu...@web.de > andreas.b.mu...@web.de > and...@web.de > > GPG key: 4096R/617B586D 2010-03-22 Andreas B. Mundt-- >Andreas B. Mundt-- > > > -- Sysadmin SPSE-Tenero Ufficio: +41 91 735 62 48 Cellulare: +41 79 629 20 63 -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127221404.ga1...@ticino.com
Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
Hi, On Fri, Jan 27, 2012 at 09:19:21PM +0100, Petter Reinholdtsen wrote: > [Andreas B. Mundt] [...] > > > The script executed right after authentication copies the user's > > Kerberos ticket to the file krb5cc_diskless which is owned by root. > > This ticket will be picked up by gssd to create the security context > > needed. However, it's needed to restart autofs, I am not exactly > > sure why. It looks like autofs caches failures in mounting a > > directory (which it tries earlier in the login process), and does > > not try again immediately when the ticket is available. > > I guess we also need to remove the file when the user log in, to make > sure other users can't use another users ticket to mount? > I think the ticket is used as if it where root's ticket, as the automounter runs under root's ID. If the ticket is removed and the automounter umounts the NFS after some time, accessing the home directory again will fail, because there is no ticket anymore to remount. The trick is a bit dirty, but so far I could not think of any way to misuse the copied ticket, as it's only accessible by root. A user logging in later or in parallel has no access. > > With these modifications fully kerberized NFSv4 mounting should be > > possible on all machines if there are no other issues like those > > reported in http://bugs.debian.org/613167#30> (pending?). I > > did not test LTSP diskless clients but a home-made chroot in > > combination with aufs. > > This approach look really promosing. What about just dropping autofs > and mount the NFS volume in the pam module instead, like pam-mount? I don't know if pam-mount has any disadvantages compared to autofs (umounting after some time of 'silence' on the file system?), but if not, it's probably a good idea to switch. Best regards, Andi -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127211156.GA9727@flashgordon
Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
[Andreas B. Mundt] > I finally figured out a way now, which works here and is not too > invasive: Cool. > First, make sure you have the package libpam-script available at the > diskless client's chroot. libpam-script allows to run a script > after successfull authentication. The script executed can be > created by running: We already use libpam-python for libpam-mklocaluser, which allow a python script to provide a pam module. Perhaps it is better to rewrite as python to avoid pulling in another dependency? > The script executed right after authentication copies the user's > Kerberos ticket to the file krb5cc_diskless which is owned by root. > This ticket will be picked up by gssd to create the security context > needed. However, it's needed to restart autofs, I am not exactly > sure why. It looks like autofs caches failures in mounting a > directory (which it tries earlier in the login process), and does > not try again immediately when the ticket is available. I guess we also need to remove the file when the user log in, to make sure other users can't use another users ticket to mount? > With these modifications fully kerberized NFSv4 mounting should be > possible on all machines if there are no other issues like those > reported in http://bugs.debian.org/613167#30> (pending?). I > did not test LTSP diskless clients but a home-made chroot in > combination with aufs. This approach look really promosing. What about just dropping autofs and mount the NFS volume in the pam module instead, like pam-mount? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127201920.gb17...@login2.uio.no
Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
Hi everybody! Since quite some time we have been thinking about how to make kerberized NFSv4 mounting of home directories work with diskless clients, where no machine credentials (keytab) are available. It was mentioned [1] that using "-n" for gssd on the diskless client might help, however this seems not to be enough. I finally figured out a way now, which works here and is not too invasive: First, make sure you have the package libpam-script available at the diskless client's chroot. libpam-script allows to run a script after successfull authentication. The script executed can be created by running: #!/bin/sh # set -e FILE=/usr/share/libpam-script/pam_script_auth cat > $FILE < /dev/null 2>&1; then exit 0 fi FILE=/tmp/krb5cc_diskless cp -v /tmp/krb5cc_pam_* \$FILE /etc/init.d/autofs restart > /dev/null exit 0 EOF chmod 0755 $FILE # The script executed right after authentication copies the user's Kerberos ticket to the file krb5cc_diskless which is owned by root. This ticket will be picked up by gssd to create the security context needed. However, it's needed to restart autofs, I am not exactly sure why. It looks like autofs caches failures in mounting a directory (which it tries earlier in the login process), and does not try again immediately when the ticket is available. In addition, add the line RPCGSSDOPTS="-n" to /etc/default/nfs-common and the line authoptional pam_script.so to /etc/pam.d/common-auth. With these modifications fully kerberized NFSv4 mounting should be possible on all machines if there are no other issues like those reported in http://bugs.debian.org/613167#30> (pending?). I did not test LTSP diskless clients but a home-made chroot in combination with aufs. Best regards, Andi [1] http://lists.debian.org/debian-edu/2010/07/msg00065.html -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127161853.GA17722@flashgordon
