crontab의 모든 명령이 "Permission denied"로 실패합니다


10

업데이트 :이 문제는 결정적으로 답변되지 않습니다.나는 다른 배포판으로 옮겼으며 그 이후 로이 문제를 관찰하지 못했습니다.당시에는 통찰력있는 답변으로 문제를 해결할 수 없었지만 연료 효율 (YMMV)이 다를 수 있습니다.

<시간>

crontab -ecrontab -l은 잘 작동합니다 :

$ crontab -l | grep -v '^#'
* * * * * /usr/bin/env
* * * * * echo 'Hello from crontab'

그러나 /var/log/syslog에서 매분 이와 같은 두 개의 메시지가 표시됩니다.

Mon DD hh:mm:01 username CRON[PID]: Permission denied

그래서 crontab을 읽는 중 이지만, 아무것도 전혀 실행할 수 없습니다 (물론 동일한 사용자로 로그인하면 명령을 확인했습니다).왜 그런지 알아?

/etc/cron.allow/etc/cron.deny가 없습니다.

crontab은 setuid 그룹으로 설정됩니다 :

$ stat --format '%A %U %G' /usr/bin/crontab
-rwxr-sr-x root crontab

crontabs 디렉토리에 올바른 권한이있는 것 같습니다 :

$ stat --format '%A %U %G' /var/spool/cron/crontabs
drwx-wx--T root crontab

크론 탭 자체는 내가 소유하고 있습니다 (놀랍게도 편집 할 수 없기 때문에) :

$ sudo stat --format '%A %U %G' /var/spool/cron/crontabs/$USER
-rw------- username crontab

crontab 그룹의 구성원이 아닙니다.

이 라인은 매분 /var/log/auth.log에 나타납니다 (@Alaa 덕분에) :

Mon DD hh:mm:01 username CRON[1752]: pam_unix(cron:session): session opened for user username by (uid=0)
Mon DD hh:mm:01 username CRON[1752]: PAM bad jump in stack

아마 PAM이 고장 났습니까?pam-auth-update (@coteyr 덕분에)에이 모든 것들이 나열되어 있으며 모두 활성화되어 있습니다 :

  • 유닉스 인증
  • 그놈 키링 데몬-로그인 키링 관리
  • eCryptfs 키 / 마운트 관리
  • ConsoleKit 세션 관리
  • 상속 가능한 기능 관리

그중 하나라도 안전하게 비활성화 할 수 있습니까?암호화 된 파일 시스템을 사용하고 있지 않습니다.

Debian bug entry을 기반으로 debconf-show libpam-runtime을 실행하려고 시도했는데 다음 오류 메시지가 나타납니다.

debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied

/etc/pam.d/cron의 내용 :

# The PAM configuration file for the cron daemon

@include common-auth

# Read environment variables from pam_env's default files, /etc/environment
# and /etc/security/pam_env.conf.
session       required   pam_env.so

# In addition, read system locale information
session       required   pam_env.so envfile=/etc/default/locale

@include common-account
@include common-session-noninteractive 

# Sets up user limits, please define limits for cron tasks
# through /etc/security/limits.conf
session    required   pam_limits.so

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
언급 된 파일 (crontab -l0, crontab -l1, crontab -l2, crontab -l3, crontab -l4)은 모두 사용자가 읽을 수 있습니다.

같은 사용자 crontab, crontab -l5, 위와 동일한 권한이 있고 crontab 그룹의 구성원이 아닌 Ubuntu 13.04를 사용하는 다른 호스트에서는 제대로 작동합니다 (명령은 기록하지만 /var/log/syslog의 출력은 아님).

<시간>

첫 번째 crontab 줄을 변경하여 :

* * * * * /usr/bin/env >/tmp/env.log 2>&1

/ tmp가 쓰기 가능한지 확인 :

$ sudo -u nobody touch /tmp/test
$ ls /tmp/test
/tmp/test
$ ls -ld /tmp
drwxrwxrwt 15 root root 12288 May 27 10:18 /tmp

crontab 명령이 전혀 실행되지 않는지 확인했습니다 : crontab -l8 메시지는 여전히 /var/log/syslog에 표시되지만 /var/log/syslog0은 생성되지 않습니다.

<시간>

random listing of /etc/pam.d settings을 기준으로 다음과 같은 불일치가 발견되었습니다.

Mon DD hh:mm:01 username CRON[PID]: Permission denied
0<시간>

PAM 패키지 설치 :

Mon DD hh:mm:01 username CRON[PID]: Permission denied
1

이걸 재설치하려고했지만 도움이되지 않았습니다 :

Mon DD hh:mm:01 username CRON[PID]: Permission denied
2

만족되지 않은 종속성으로 인해 제거하고 다시 설치할 수 없습니다.

1

Your PAM configuration is out of sorts. This is common if you have used "external" authentication methods like fingerprint scanners, LDAP accounts, USB Keys or the sort. Basically cron can't work a fingerprint scanner so it can't login as you.

You need to remove the offending configuration from /etc/pam.d/common-* though tracking it down can be a bit difficult, specially if you didn't enable something manually (for example if a Finger print scanner setup script turned something on).

I can't help much with telling you what should be in those files. A lot of things could be different depending on your setup. But disabling "required" auth methods till your left with just "Unix Authentication" may be a good first step.

You can do this by running pam-auth-update as root and un-checking the other boxes. Be very very careful as this can leave you with a system you can not login to if done incorrectly. Disable them one at a time, reboot for safety, and test. NEVER DISABLE "Unix Authentication"


2

PAM bad jump in stack is a big clue.

Your /etc/pam.d/cron differs from the stock version with the addition of one extra line at the end:

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

The success=1 bit means "if this module succeeds, skip the next rule". Only there's no next rule, as this is the last line in your PAM configuration.


1

We were trying to schedule cron from a LDAP user (non machine user) and getting the same permission denied for even putting basic echo command or script in crontab, while it was working completely file from machines users (who have entries in /etc/passwd). Taking help from the detailed troubleshooting comments added by OP, we checked file /var/log/auth.log where we found this line:

pam_sss(cron:account): Access denied for user my_username: 6 (Permission denied)

A bit of Google search took me to this answer which worked for us. Adding the details here as well.

In /etc/sssd/sssd.conf, under our domain, we added an entry (see last line) like this.

[domain/my.domain.com]
....
ad_gpo_map_interactive = +cron

And then just did sudo service sssd restart and it works like a charm.