Over my objections, some of our users want to use at on one of the servers. So I put their usernames in the /etc/at.allow file, but when they try to run at, they get:

$ at
PAM authentication failure: Authentication failure
You do not have permission to use at.

The /etc/at.allow file looks fine. Restarting atd doesn't help. No error messages get logged in /var/log/messages.

So questions:

Does anyone know why I would be getting a PAM authentication failure?

Is there any way to configure atd logging so I can trace exactly why it's failing?

Here's the /etc/pam.d/atd file, just in case:

auth sufficient pam_rootok.so
auth required pam_env.so
auth include system-auth
account include system-auth
session include system-auth
session required pam_loginuid.so

Thanks.

So yeah, I fixed this. It turns out to have nothing at all to do with PAM authentication and everything to do with the sticky bit not being set. So all I did was:

chmod u+s /usr/bin/at

And now everything works.

Hooray for misleading error messages.

worked for me too.. if anybody knows a better solution.. tell us.

Actually, that's the setuid bit ... you might not want to do that.

I know this is an old thread, but I never found the answer online, so I thought I'd update this with my solution.

First, granting "u+s" or SETUID permission isn't a good idea because it will then run "at" as the owning user (probably "root") whenever a user executes it. I'm not sure how much permission that gives the user, but I'm thinking that "root" can get "at" to run just about anything.

Now, the solution I found is to find your "at.deny" and/or "at.allow" files (in my case, SUSE 10, it is in "/etc/"), and make sure these files have "read" permission for all users. I don't know why this isn't the default, but it wasn't for me. Once I did this then the error message "You do not have permission to use at" disappeared! I guess it wasn't able to check who didn't have permission in "at.deny" when I ran it as my owner user, so it just denied everyone!

I've got some issues with /var/spool/atjobs now, so I'll update when I've figured that out.