cron 강화: cron.allow/cron.deny에도 불구하고 /var/spool/cron/crontab의 작업이 계속 실행되는 이유는 무엇입니까?

cron 강화: cron.allow/cron.deny에도 불구하고 /var/spool/cron/crontab의 작업이 계속 실행되는 이유는 무엇입니까?

시나리오: www-data가 cron을 사용하지 못하도록 하고 싶습니다.

다른 사용자를 추가했습니다 cron.allow. 다른 사용자의 작업이 실행되는 것을 원하지 않습니다.chmod 600

그래도 crontab -u www-data -ecrontab을 사용하면 편집이 가능합니다.
저는 괜찮습니다. 이를 사용하여 변조 시도를 감지할 수 있습니다. cron.denycrontab은 어떻게 생성되든 편집이 불가능합니다.

crontab -u www-data -e

사용자 www-data는 이 프로그램(crontab)을 사용할 수 없습니다.

이것이 클린 서버(Ubuntu 18.04)에서 제가 처음으로 하는 일입니다. 몇 시간 후 암호화폐 채굴자가 들어와 어떻게든 글을 쓰고 /var/spool/cron/crontab/www-data작업이 실행됩니다. 하지만 cron.allow여전히 cron.deny같은 곳에 있다는 뜻설정이 무시됨.

...이것은 예상된 동작이 아닙니다...

fileCrontabWww="/var/spool/cron/crontab/www-data"
echo 'MAILTO=root' > "$fileCrontabWww"
chown root:root "$fileCrontabWww"
chmod 200 "$fileCrontabWww"

작업이 더 이상 실행되지 않습니다. 하지만 cron이 루트로 파일을 읽고 있기 때문에 200개의 권한으로 잠가야 합니다. journalctl -u cron보여주다:

cron[680]: (www-data) 안전하지 않은 모드(예상 모드 0600) (crontabs/www-data)

아 글쎄. 나는 필요한 것을 가지고 있습니다. 그러나 이를 강화하기 위해 cron과 어떻게 작동합니까? 아니면 이전에 경험해 본 적이 없는 사용 사례 시나리오가 있습니까?

또 다른 흥미로운 사실은 다음과 같습니다.https://help.ubuntu.com/community/CronHowto

/etc/passwd에 사용자를 입력하고 /etc/shadow에 사용자의 crontab을 입력하지 않으려는 경우 /etc/shadow에 표시되지 않는 시스템의 사용자 ID에는 작동 가능한 crontab이 없습니다.

이는 예상치 못한 부작용으로 인해 실제로 제한적인 방법으로 사용할 수 없습니다.

~에서`/etc/crontab`, `/etc/cron.d/` 및 `/var/spool/cron/crontabs/root` 아래의 파일 간의 차이점은 무엇입니까?

/var/spool/cron/crontabs는 crontab 명령으로 관리되는 콘텐츠입니다.

그러나 관리 도구와 작업자는 서로 분리되어 일관되지 않은 동작을 보였습니다. 여기서 작업 흐름은 무엇입니까?

관련 정보