On Mon, Mar 21, 2011 at 11:32 PM, Russ Allbery <[email protected]> wrote: > Alec Warner <[email protected]> writes: > >> When creating a new ticket cache libpam-krb5 stashes the cache in a >> temporary location; > >> api-auth.c: pamret = pamk5_cache_init_random(args, creds); >> api-password.c: pamret = pamk5_cache_init_random(args, creds); > >> in cache.c: pamk5_cache_init_random: >> char cache_name[] = "/tmp/krb5cc_pam_XXXXXX"; >> /* Store the obtained credentials in a temporary cache. */ >> pamret = pamk5_cache_mkstemp(args, cache_name); >> if (pamret != PAM_SUCCESS) >> return pamret; > >> If /tmp is full this call fails and the entire pam stack will fail. >> When the rootfs is full users kind of expect to be able to do normal >> operations such as unlocking their screen or using sudo to gain root >> access to delete files. > > Well, those are going to fail anyway unless you've configured something > other than the default location for storing the final ticket cache, since > the default location for it is also in /tmp. Usually systems are pretty > unhappy if there's absolutely no room left in /tmp, and note that root > logins or anything that's setuid (like sudo) get to use root's additional > margin of free space, if you didn't disable that when you built the > filesystem. But sure, I see what you're saying.
The internal bug that triggered this bug was that a user had locked his screen and gone off to lunch while a job on his machine filled his disk. His screensaver is kerberized, ssh to his workstation is kerberized, and even his local login is kerberized. We do not have accessible root accounts (everyone has to login and then sudo) so he was forced to reboot boot into single user mode to fix it; it was a poor failure mode is all. Yes we set a custom ccache dir. > >> It would be nice if we could control where the tempfile was written in >> /etc/krb5.conf like many of the other pam options. > > Yeah, I can do that. I'll try to get that into the next upstream > release. Thanks I appreciate it. > > -- > Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> > > -- > You received this bug notification because you are a member of Goobuntu > Team, which is a direct subscriber. > https://bugs.launchpad.net/bugs/732990 > > Title: > libpam-krb5 writes to /tmp, does not work when disk is full. > > Status in “libpam-krb5” package in Ubuntu: > New > > Bug description: > Binary package hint: libpam-krb5 > > When creating a new ticket cache libpam-krb5 stashes the cache in a > temporary location; > > api-auth.c: pamret = pamk5_cache_init_random(args, creds); > api-password.c: pamret = pamk5_cache_init_random(args, creds); > > in cache.c: pamk5_cache_init_random: > char cache_name[] = "/tmp/krb5cc_pam_XXXXXX"; > /* Store the obtained credentials in a temporary cache. */ > pamret = pamk5_cache_mkstemp(args, cache_name); > if (pamret != PAM_SUCCESS) > return pamret; > > If /tmp is full this call fails and the entire pam stack will fail. > When the rootfs is full users kind of expect to be able to do normal > operations such as unlocking their screen or using sudo to gain root > access to delete files. > > It would be nice if we could control where the tempfile was written in > /etc/krb5.conf like many of the other pam options. > > antarus@goats ~/local/libpam-krb5-4.2 $ lsb_release -rd > Description: Ubuntu 10.04.1 LTS > Release: 10.04 > > antarus@goats ~/local/libpam-krb5-4.2 $ apt-cache policy libpam-krb5 > libpam-krb5: > Installed: 4.2-1 > Candidate: 4.2-1 > > I expect to be able to configure libpam-krb5 to write to a tmpfs or > something that is harder to fill up. An attacker could fill /tmp and > cause any krb5-based authentication to fail. > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/732990 Title: libpam-krb5 writes to /tmp, does not work when disk is full. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
