두 setuid 프로그램 모두 구성 파일을 /usr/bin/bar공유합니다 . 구성 파일은 민감한 정보를 포함하고 있으므로 스키마에 있습니다. 프로그램은 다음으로 시작합니다 (즉, 사용자로서/usr/bin/bazfoo0640bar:bar술집,그룹술집baz:baz) ;사용자 변경은 선택 사항이 아닙니다.그룹을 변경하는 것조차 더 나은 옵션은 아닙니다.
/etc/bar/foo단일 구성 파일을 및 으로 하드 링크하고 싶습니다 /etc/baz/foo. 그러나 내가 아는 한 파일은 root:bar또는 에 속해야 하기 때문에 실패합니다 root:baz.
barbaz가능한 해결 방법: 구성원이 bar및 인 새 그룹을 만듭니다 baz. foo속하게 하세요 root:barbaz.
나에게 이것은 매우 과감한 해결책처럼 보입니다. foo두 프로그램 간에 구성 파일을 공유 하는 더 깨끗하고 깔끔한 방법이 있습니까 ?
현재 나는 이 파일의 동일한 복사본 두 개를 유지하고 있습니다. 이것은 작동하지만 분명히 잘못된 것입니다. 무엇이 옳은가?
참고: 저는 Unix 커뮤니티나 setgid(2)에 대한 경험이 거의 없습니다.
답변1
두 그룹의 사람들이 파일을 읽을 수 있도록 ACL을 사용할 수 있습니다.
chgrp bar file
chmod 640 file
setfacl -m g:baz:r-- file
이제 사용자 bar와 그룹 모두가 baz파일을 읽을 수 있습니다 .
예를 들어, 이는 모드 640의 bin:bin이 소유한 파일입니다.
$ ls -l foo
-rw-r-----+ 1 bin bin 5 Aug 17 12:19 foo
이는 +ACL이 설정되었음을 의미합니다. 살펴보겠습니다.
$ getfacl foo
# file: foo
# owner: bin
# group: bin
user::rw-
group::r--
group:sweh:r--
mask::r--
other::---
우리는 이 줄을 볼 수 있습니다 group:sweh:r--. 이는 그룹의 사람들 sweh이 읽을 수 있다는 것을 의미합니다.
이봐, 그게 나야!
$ id
uid=500(sweh) gid=500(sweh) groups=500(sweh)
예, 파일을 읽을 수 있습니다.
$ cat foo
data
답변2
다음 진술을 재고해 볼 수도 있습니다.
bar가능한 해결 방법: 구성원이 및 인 새 그룹 barbaz를 만듭니다baz.foo속하게 하세요root:barbaz.나에게 이것은 매우 과감한 해결책처럼 보입니다.
foo두 프로그램 간에 구성 파일을 공유 하는 더 깨끗하고 깔끔한 방법이 있습니까 ?
새 그룹을 만드는 데 왜 그렇게 가혹한가요? 이는 ACL에 비해 다음과 같은 장점이 있습니다.
/usr/bin/bar이것을 명령 및 가정으로 명시했지만/usr/bin/baz두 프로그램이 구성 파일을 공유할 수 있다는 점은 관련이 있습니다. 이는 이들 프로그램이 자연스럽게 연관되어 있음을 시사한다. 이들을 위한 새 그룹을 만드는 것은 실제로 존재하고 동작(예: 공개 프로필을 읽을 수 있는 권한)을 유발해야 하는 관계를 설명하는 것처럼 보입니다.- 그룹화를 통해 이 문제를 해결하는 방법은 다음과 같습니다.모든Unix, 이는 동일한 메커니즘을 사용하여 모든 Unix 또는 Unix 계열 시스템에서 정확히 동일한 방식으로 작동할 수 있음을 의미합니다. ACL은 훨씬 더 복잡하며 이식성이 문제가 될 수 있습니다.
개인적으로 저는 ACL이 엄격한 솔루션인 반면 그룹화는 더 간단하고 전통적인 Unix 방식이라고 생각합니다.
답변3
나는 이것이 ACL(액세스 제어 목록)의 일반적인 사용이라고 생각합니다. 프로필의 ACL에 두 사용자(또는 그룹)를 모두 추가합니다.
/etc/foo root:root rw------- # Traditional Unix ownership and permission for foo
$ setfacl -m user:bar:rw- /etc/foo # 사용자 bar가 foo를 읽고 쓸 수 있도록 허용 $ setfacl -m user:baz:rw- /etc/foo # 또한 사용자 baz가 foo를 읽고 쓸 수 있도록 허용합니다.
먼저 acl 패키지를 설치해야 할 수도 있습니다.
답변4
아직 언급되지 않았기 때문에 제출하겠습니다. 비록 이것이 귀하가 원하는 것이 아닐 수도 있지만 비슷한 문제를 겪고 있는 다른 사람들에게는 답변이 될 수 있습니다.
"새로운" "클라우드" 접근 방식은 모든 구성을 하나의 솔루션으로 처리하는 것입니다.구성 관리시스템(예:요리사,인형, 또는안시푸르). 서버에 두 개의 서로 다르지만 동일한 파일이 있다는 것은 중요하지 않습니다. 둘 다 구성 관리 시스템에 있는 단일 파일의 복사본이기 때문입니다.
이렇게 하면 가장 큰 장점은 구성이 다음과 같다는 것입니다.버전이 매겨진(및 기타 모든 구성), 동일하거나 거의 동일한 새 서버를 배포하는 것이 매우 쉬워서 자동화할 수 있습니다.
(기록을 위해 구성 관리를 사용하지 않으므로 @drg의 답변과 같은 그룹 시스템을 사용합니다).