☰

소유자가 파일 및 폴더를 생성하도록 강제

tag-icon • tag-icon debian permissions filesystems
소유자가 파일 및 폴더를 생성하도록 강제

여러 사용자가 공유하는 데이터가 포함된 디렉터리가 있습니다. 디렉토리 및 그 아래의 모든 콘텐츠에 대한 액세스는 해당 사용자에게 추가되는 디렉토리 그룹에 의해 제어됩니다. 따라서 "고정 그룹" chmod g+s폴더 집합을 만들었습니다. 디렉토리에는 디렉토리와 파일의 트리 구조가 포함되며 총 파일 수는 수백만 개가 될 수 있습니다. 파일이 상당히 작아서 50MB를 초과할 것으로 예상되지 않습니다.

내 문제는 파일이나 디렉토리의 소유자가 여전히 그것을 만든 사용자라는 것입니다. 따라서 액세스 그룹에서 사용자를 제거해야 하더라도 해당 사용자의 액세스 권한을 완전히 제거하지는 않습니다.

그래서:

모든 파일과 하위 디렉터리의 소유자가 동일한지 확인하기 위해 누락된 다른 옵션이 있습니까?

cron-job을 사용하여 전체 디렉터리를 주기적으로 탐색할 수 있으면 좋겠지만 이는 본질적으로 일회성 pr-file 명령에 비해 비효율적입니다.

내가 하나 찾았어예INotify를 사용하지만 스크립팅이 필요하기 때문에 유지 관리가 많이 필요한 것 같습니다.

ACL이 소유권을 강제하는 데 도움이 될 수 있는지 확인할 수 없었습니다.

이를 수행하는 더 현명한 방법이 있습니까?

내가 원하는 것은 사용자에게 그룹을 추가하여 공유할 수 있는 디렉토리를 갖는 것입니다. 이 디렉터리에 생성된 모든 항목은 상위 디렉터리의 권한 체계를 상속합니다. 내가 시도하는 것보다 더 좋은 방법이 있다면 나는 모두 귀를 기울이겠습니다.

답변1

setuid기본 소유자를 "자동으로" 설정하려면 이와 유사한 동작이 필요합니다 setgid. 그러나 FreeBSD에서는 이를 구성할 수 있지만 다른 UNIX 및 Linux 시스템에서는 이를 무시합니다 u+s. 그러나 귀하의 경우에는 다른 솔루션이 있을 수 있습니다.

내가 원하는 것은 사용자에게 그룹을 추가하여 공유할 수 있는 디렉토리를 갖는 것입니다. 이 디렉터리에 생성된 모든 항목은 상위 디렉터리의 권한 체계를 상속합니다. 내가 시도하는 것보다 더 좋은 방법이 있다면 나는 모두 귀를 기울이겠습니다.

따라서 기본적으로 내가 이해하는 바에 따르면 그룹 메커니즘을 사용하여 디렉토리에 대한 액세스를 제어하려고 합니다. 그러나 전체 디렉터리 구조에 대한 권한을 제한할 필요는 없습니다. 실제로 디렉터리 --x실행 비트가 바로 여러분에게 필요한 것일 수도 있습니다. 예를 들어 보겠습니다. 만약 그러하다면...

  • 디렉토리 액세스를 제어하는 ​​그룹 group_dir은 입니다 ourgroup.
  • 그룹에 속한 사람만 ourgroup액세스할 수 있습니다 group_dir.
  • user1그리고 user2에 속해 있습니다 ourgroup.
  • 기본 umask는 0022입니다.

...다음 설정을 고려하세요.

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

여기서는 각 프로젝트가 소유자에 의해 생성된다고 가정합니다.

이제 이 설정에서는 다음과 같습니다.

  • 모든 사람은 모든 디렉토리를 자유롭게 탐색할 수 있습니다 ourgroup. 그룹에 속한 사람은 누구나 group_dir내부 어디에서나 파일을 생성, 이동, 삭제할 수 있습니다(더 깊은 곳은 불가능).
  • 거기에 없는 사람은 ourgroup그곳에서 차단되므로 group_dir그 아래에 있는 어떤 작업도 수행할 수 없습니다. 예를 들어 user3(의 구성원이 아닌 )은 파일 자체에 대한 권한이 있더라도 ourgroup읽을 수 없습니다 .group_dir/user2_submission/READMEr--

그러나 이 경우에는 작은 문제가 있습니다. 일반적인 umask로 인해 사용자가 만든 프로젝트를 그룹의 다른 구성원이 조작할 수 없습니다. 여기가 ACL이 작동하는 곳입니다. 기본 권한을 설정하면 umask 값에 관계없이 모든 것이 작동하도록 할 수 있습니다.

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

이 호출은 다음을 설정합니다.

  • rw(x)소유자에 대한 기본 권한입니다.
  • rw(x)그룹의 기본 권한입니다.
  • 다른 사용자에게는 기본적으로 권한이 없습니다. 이후부터 참고해주세요다른 사람어쨌든 액세스할 수 없으며 group_dir, 현재보다 낮은 권한을 가지고 있는 것은 중요하지 않습니다.

이제 프로젝트를 생성하면 다음과 같습니다 user2.

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

이 ACL을 사용하여 이전 구조를 다시 빌드할 수 있습니다.

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

마찬가지로 모든 항목은 소유자에 의해 생성됩니다.

또한 디렉터리를 사용하는 사용자에게 더 강력한 기능/보안을 제공하려는 경우 고정 비트를 고려할 수 있습니다. 예를 들어, 다음과 같이 하면 user1삭제가 방지됩니다 ( user2_submission그가 가진 -w-권한 으로 인해 group_dir).

$ chmod +t group_dir/

이제 디렉토리를 user1삭제하려고 하면 user2멋진 Operation not permitted.group_dir

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ >     user2_submission/README
user1@host $ file  user2_submission/README
user2_submission/README: empty (uh-oh)

고려해야 할 또 다른 사항은 우리가 사용하는 ACL 설정입니다.기본권한. 따라서 프로젝트 소유자는 이와 관련된 권한을 변경할 수 있습니다. 예를 들어 user2완벽하게 작동합니다 ...

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

...그래서 그의 전체 커밋 디렉터리는 그룹의 어느 누구도 사용할 수 없습니다.

그러나 처음에는 그룹의 모든 사람에게 전체 액세스 권한을 부여하려고 했기 때문에 rws이러한 사용자를 신뢰하고 이들이 악의적인 작업을 많이 수행할 것으로 기대하지 않는다고 가정합니다.

답변2

이를 수행하는 더 현명한 방법이 있습니다. set-gid를 사용하고기본ACL. 분명히 acl 지원 파일 시스템이 필요합니다. 공유하려는 디렉터리가 있고 /var/grpdir그룹 구성원이 sharing해당 디렉터리에 액세스할 수 있어야 한다고 가정합니다.

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

기본 ACL은 기본 ACL을 사용하여 디렉터리 내에 생성된 하위 디렉터리에 상속됩니다. 즉, 생성된 모든 파일에는 /var/grpdir디렉터리의 setgid 비트를 통해 그룹이 설정된다는 의미입니다. sharing또한 특정 사용자나 그룹에 대해 ACL을 지정하지 않기 때문에 기본 Linux 스타일 권한을 재정의하는 기본 ACL을 상속합니다. 이는 모든 파일이 <user>:sharing소유권과 권한을 가지고 생성된다는 의미입니다 rw-rw----. 디렉터리는 기본 ACL이 상위( )와 동일하게 설정되어 있고 /var/grpdir사용자 및 그룹에 대해 실행 가능한 비트가 설정되어 있다는 점을 제외하면 동일합니다 . 그룹에서 사용자를 제거하면 sharing해당 사용자는 디렉터리(또는 디렉터리를 소유하고 있더라도 디렉터리에 있는 파일)에 액세스할 수 없습니다.

정기적으로 권한을 수정하기 위해 cronjob을 사용하는 것과 달리 권한은 새로 생성된 파일 및 디렉터리로 자동 업데이트되므로 항상 동기화됩니다. 이 솔루션은 가볍습니다. 데몬이 필요하지 않으며 권한을 한 번에 수정할 때 IO 스파이크가 없습니다.

답변3

나는 이것을 수행하는 좋은 방법을 모른다. 이를 달성하는 기술적으로 가장 간단한 방법은 FUSE 파일 시스템을 사용하는 것입니다. 물론, 아직 아무도 하고 있지 않다면 해야 할 일이 많이 남아 있습니다.

대안:

  1. 삼바를 사용하세요. 삼바에는 force user매개변수가 있습니다. 디렉토리를 로컬로 내보내고 로컬로 마운트할 수 있습니다. 더 빠르게 액세스할 수는 없지만 루프백 네트워크만 포함되므로 허용될 수 있습니다.

  2. FAT32와 같은 Linux가 아닌 파일 시스템을 사용하십시오. 이를 설치하려면 사용자가 구성해야 합니다. 액세스 권한은 상위 디렉터리에서 처리되어야 합니다.

답변4

당신은 그것을 사용할 수 있습니다이노티파이 도구아래와 같이 간단한 bash 스크립트를 작성합니다. Inotify는 이 디렉토리를 주의 깊게 관찰할 것입니다.회로망이런 일이 있을 때마다 어떻게든 해라. 디렉토리 생성웹 디렉토리에서 발생합니다. 많은 이벤트가 존재합니다. 구글링해서 보셔도 되고 이거 보시면 됩니다장소

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done

관련 정보