crontab에 연결하는 것이 나쁜가요?

아니요!

그러지 마세요!

반드시 crontab귀하(및 다른 모든 사람)의 사본을 홈 디렉토리와 같은 어딘가에 저장하되 시스템 파일은 건드리지 마십시오.

crontab -l >my_crontab    # Start by getting current rules

vi my_crontab             # Edit my copy of the crontab file
crontab my_crontab        # Install it

$HOME/.crontab(개인적으로 는 사용자별로 복사본을 사용합니다 .)

시스템 파일을 추적하는 더 좋은 방법은 소스 코드 저장소(git, cvs, mercury 등)를 만들고 이를 사용하여 변경 사항을 추적하는 것입니다. A를 Makefile사용하여 관련 시스템 디렉터리에 변경 사항을 설치하고 관련 서비스를 다시 시작할 수 있습니다. 이 경우 간단히 sudo make install.

이것작동하지 않습니다, 적어도 Debian 계열 시스템(시스템이 아닌) 사용자의 심볼릭 링크 또는 하드링크 crontab 파일은 다음과 같습니다.완전히 무시됨). crontabcrontab 파일을 변경하는 데 사용하는 경우 에도 실패합니다. cron 버전이 여전히 심볼릭 링크된 crontab 파일을 허용하는 경우잠재적인 보안 취약점 유발crontab 파일의 일관성이 더 이상 확인되지 않기 때문입니다.

Symlink 솔루션을 사용하면 crontab -e사용자(또는 일부 설치 스크립트)가 crontab 파일을 변경하면 충돌이 발생합니다.

crontab: crontabs/username: rename: Operation not permitted

/var/spool/cron/crontabs/username 이전 파일을 대체 하기 위해 임시 파일을 즉시 이동하기 때문입니다 .

crontab에는 많은 추가 보안 검사가 내장되어 있으므로 cron 시스템을 사용하여 시스템을 손상시킬 수 없습니다. 예를 들어 cron 파일을 설치하거나 변경하기 전에 해당 파일의 내용을 확인합니다. 유효하지 않은 cron 파일은 cron데몬을 충돌시킬 수 있거나 (적어도 이론적으로는) 시스템에서 더 많은 권한을 얻기 위해 남용될 수 있습니다. 귀하의 솔루션에서는 crontab 파일이 더 이상 확인되지 않습니다.

링크가 필요하지 않습니다. 일일 설치를 위해 원하는 crontab 파일(/home/user/my_crontab)에 한 줄을 추가하기만 하면 됩니다.

58 23  *   *   *     crontab /home/user/my_crontab
00 12  *   *   *     bash /home/user/do-other things.

다음을 설치하여 프로세스를 시작하십시오.crontab /home/user/my_crontab

앞서 언급했듯이 대부분의 CRON 구현은 심볼릭 링크를 읽지 않기 때문에 대부분의 시스템에서는 작동하지 않습니다. 상황을 더 복잡하게 만들기 위해 cron은 /var에 있는 몇 안 되는 시스템 구성 파일 중 하나입니다. /var에서 파일을 가져오는 것보다 /etc/crontab사용자 정의 파일이 더 나은 대안인 경우 가 많습니다 . /etc/cron.d/<yourfilename>또한, 표준 소스를 갖는 것이 좋습니다(버전을 제어하는 ​​경우 더욱 좋습니다). 이를 통해 다음과 같은 것을 사용할 수 있습니다.골키퍼를 기다려라버전 관리 백업을 유지하십시오. 하지만 여러분처럼 저도 모든 것을 한 곳에 보관하는 것을 좋아합니다(내 구성 파일 etc과 도트 파일은 내 홈 디렉터리의 단일 버전 제어 폴더에 있으므로 재구성 및 복원이 훨씬 쉬워집니다). 따라서 1개 미만만 필요한 경우 파일을 보면 etc keeper가 파일의 %를 과도하게 사용하는 것으로 나타났습니다.

CRON이 실행될 때마다 새로운 크론탭을 지속적으로 설치하는 대신(이제 누군가가 집에서 사용자가 소유한 파일에 액세스하여 루트 수준 크론으로 승격된 악성 콘텐츠를 추가하는 경우 이는 보안 결함입니다) cron이 실행될 때마다 디렉터리:

0 * * * * <username> cp /etc/cron.d/<your custom cronfile> /home/user/<where you want your backup>

그러면 백업은 매시간 실행되는 동안 시스템이 켜져 있을 때마다 버전 제어 영역에 저장됩니다(또는 시스템이 일반적으로 켜져 있는 시간으로 설정하기만 하면 됩니다). cron을 업데이트하려는 경우 사용자 수준 백업 대신 소스를 루트로 수정할 수 있습니다. 예, 이상적인 견해는 아니지만 CRON의 보안 요구 사항을 고려할 때 전체 또는 작은 부분 등을 더 해킹적인 방식으로 백업하지 않고도 구성의 정식(버전 제어) 소스를 유지할 수 있습니다.

보안에 대한 원래 질문에 대해: /etc기본 사양 파일에 링크한 파일 중 하나라도 명령을 실행하기 위해 더 높은 액세스 권한을 가진 프로세스(예: CRON)에서 사용되는 경우 보안 위험이 있습니다(아마도 크지는 않지만). 열려 있는 포트, 방화벽 및 단일 사용자 시스템이 없습니다. 누구든지 파일에 액세스할 수 있으면 루트로 명령을 실행할 수 있기 때문입니다(이것이 아마도 CRON이 심볼릭 링크를 허용하지 않는 이유일 것입니다). 읽기 수준 구성을 위해서만 무언가를 저장하는 경우(예: /etc/fstab여전히 위험할 수 있지만 실행 프로세스의 기능 및 작업에 따라 덜 위험할 수 있습니다. 하지만 귀하처럼 방화벽이 있는 서버리스 단일 사용자 시스템에 대해서는 약간의 위험을 감수합니다. 당신은 깨끗한 버전 제어 백업을 한 곳에 보관하고 싶지만 이 경우 많은 시스템이 당신보다 훨씬 더 큰 공격 표면을 가지고 있기 때문에 CRON은 그렇게 할 수 없습니다.