Search Results

Search found 3 results on 1 pages for 'j stoever'.

Page 1/1 | 1 

• .pam_environment in kerberized nfs4 home directory

  - by Paul Stoever

  How can I get pam_env to read the user's .pam_environment file, if the user's file is located in a kerberized NFS4 mount? The file and directory permissions for the .pam_environment file are set in a way, that allows the local root to read the file. Reading .pam_environment only fails on the first login. Subsequent logins successfully read the file. The client uses Ubuntu 12.04 Desktop, NFS/Kerberos server is 12.04 Server. The Kerberos/NFS4 stuff works with exception of this. From /var/log/auth for first login: ... lightdm: pam_krb5(lightdm:auth): user USERNAME authenticated as USERNAME@REALM lightdm: pam_unix(lightdm:session): session closed for user lightdm lightdm: pam_env(lightdm:setcred): Unable to open config file: USERHOME/.pam_environment: Permission denied lightdm: pam_env(lightdm:setcred): Unable to open config file: USERHOME/.pam_environment: Permission denied lightdm: pam_unix(lightdm:session): session opened for user USERNAME by (uid=0) ...

  Read the article

• DegradedArray event on /dev/md0 without actually having a RAID

  - by J. Stoever

  Since I upgraded from Ubuntu LTS 10 to LTS 12, I have been getting error messages like: N 60 mdadm monitoring Mon Sep 3 06:38 31/1022 DegradedArray event on /dev/md2:Ubuntu-1004-lucid-64-minimal N 61 mdadm monitoring Mon Sep 3 06:38 31/1022 DegradedArray event on /dev/md0:Ubuntu-1004-lucid-64-minimal N 62 mdadm monitoring Mon Sep 3 06:38 31/1022 DegradedArray event on /dev/md1:Ubuntu-1004-lucid-64-minimal We do not have a RAID setup, and only have a single hard drive. Ideas ?

  Read the article

• Double hashing passwords - client & server

  - by J. Stoever

  Hey, first, let me say, I'm not asking about things like md5(md5(..., there are already topics about it. My question is this: We allow our clients to store their passwords locally. Naturally, we don't want them stored in plan text, so we hmac them locally, before storing and/or sending. Now, this is fine, but if this is all we did, then the server would have the stored hmac, and since the client only needs to send the hmac, not the plain text password, an attacker could use the stored hashes from the server to access anyone's account (in the catastrophic scenario where someone would get such an access to the database, of course). So, our idea was to encode the password on the client once via hmac, send it to the server, and there encode it a second time via hmac and match it against the stored, two times hmac'ed password. This would ensure that: The client can store the password locally without having to store it as plain text The client can send the password without having to worry (too much) about other network parties The server can store the password without having to worry about someone stealing it from the server and using it to log in. Naturally, all the other things (strong passwords, double salt, etc) apply as well, but aren't really relevant to the question. The actual question is: does this sound like a solid security design ? Did we overlook any flaws with doing things this way ? Is there maybe a security pattern for something like this ?

  Read the article

1