☰

배경

tag-icon • tag-icon ubuntu sftp acl umask
배경

나는 다음과 같은 설정을 가지고 있습니다 :

  • Ubuntu 14.4 서버는 프런트 엔드 영역에서 SFTP 서비스를 제공합니다.
  • 외부 클라이언트는 파일을 업로드할 수 있습니다.
  • 다른 서버에 있는 백엔드 프로세스는 업로드된 파일을 추적하고 일부 백엔드 작업을 트리거하며 작업 결과에 따라 파일을 수정합니다.

SFTP 사용자는 자신이 업로드한 파일을 소유합니다. SFTP 사용자와 백엔드 프로세스는 동일한 그룹의 구성원입니다. umask가 0007이면 백엔드 프로세스가 이러한 파일에 액세스하고 수정할 수 있습니다.

그러나 일부 사용자는 파일을 업로드합니다.약 600피트백엔드 프로세스가 이러한 파일을 처리할 수 없도록 권한을 부여합니다.

권한(umask, acl)을 제한하는 방법은 많지만 권한이 너무 많은 업로드된 파일에 대해 그룹 액세스 권한을 자동으로 부여하는 방법을 찾을 수 없습니다.

600 또는 640 권한으로 업로드된 파일을 660 권한으로 자동 변환하는 방법이 있나요?

답변1

이것은 흔한 상록수이다 sftp. ~에서뿌리:

배경

이는 sftp파일 공유와 관련된 오랜 문제입니다. 생성된 권한은 클라이언트 파일의 원래 권한을 기반으로 하며 umask( -u) 매개변수는 이러한 권한을 강제하지 않고 불필요한 권한만 제거하기 때문입니다. 즉, 사용자가 권한이 있는 파일을 업로드하려고 시도하는 경우에만 0777파일이 에 적용되고 제거됩니다 0775. 그렇지 않으면 파일은 그대로 유지됩니다. 예를 들어 사용자의 파일 시스템에 권한이 있는 파일이 저장되어 있는 경우 0700해당 파일은 로도 표시됩니다 0700.

해결책

최근 우리는 새로 업로드된 파일에 대해 정확한 권한을 적용하는 패치를 적용하여 Fedora에서 이 문제를 해결했습니다. 이는 다음을 기반으로 합니다.

https://bugzilla.mindrot.org/show_bug.cgi?id=1844

몇 달 안에 CentOS에서 사용할 수 있게 될 예정이지만, 데비안에서도 사용할 수 있을지는 확실하지 않습니다.

해결책

cron잘못된 권한을 수정하는 일부 일반 실행 스크립트(from) 외에는 우아한 솔루션이 없습니다. 이것은 아마도 bash의 약간의 농담일 수도 있지만 몇 가지를 생각해 볼 수 있을 것 같습니다. 관심이 있으시면 이에 대해 자세히 설명하겠습니다.

더반?

데비안 기반 시스템의 경우 해결 방법이 있을 수 있습니다 bindfs. 기본적으로 한 디렉터리를 다른 디렉터리에 마운트하고 모든 권한이 원하는 방식으로 작동하도록 강제할 수 있습니다.

답변2

드디어 iwatch를 사용하게 되었습니다.

/etc/default/iwatch:

START_DAEMON=true
CONFIG_FILE=/etc/iwatch/iwatch.xml

/etc/iwatch/iwatch.xml:

<?xml version="1.0" ?>
<!DOCTYPE config SYSTEM "/etc/iwatch/iwatch.dtd" >

<config>
  <guard email="" name=""/>
  <watchlist>
    <title>Fix SFTP rights of uploaded files -- grant group access</title>
    <contactpoint email="" name=""/>
    <path type="recursive" alert="off" exec="chmod g+rw %f" events="close_write">/home/sftpusers</path>
  </watchlist>
</config>

여기서 /home/sftpusers는 sftp 사용자의 홈 디렉토리가 있는 곳입니다.

이렇게 하면 sftp 사용자가 파일을 업로드할 때마다(close_write 트리거) 즉시 chmod g+rw가 처리됩니다.

이것은 내 문제를 아주 잘 해결했습니다.

관련 정보