Linux 시스템에서 UID / GID를 동기화하면 어떤 이점이 있습니까?


24

다른 Linux 시스템에서 UID / GID를 동기화하는 방법에 대해 자세히 알아보기 전에 실제로 어떤 이점이 있는지 알고 싶습니다.

소유권이 "자연스럽게"유지되므로 파일 동기화가 비교적 쉽다는 것을 알고 있습니다. 그러나 이것은 전송 서비스에 따라 다르게 달성 될 수도있다.

일관된 UID / GID의 이점이있는 다른 것이 있습니까?


4
uid / gid를 변경할 때 아카이브 (tar 파일 등) 및 uidname / groupname 대신 숫자 ID를 사용할 수있는 conf 파일을 업데이트하도록 잊지 마십시오.
Olivier Dulac 2016 년

답변:


31

기술 부채

아래의 이유로 인해 기술 부채 가 누적되는 것을 피하기 위해이 문제를 조기에 해결 하는 것이 훨씬 간단 합니다 . 이 상황에서 이미 자신을 발견하더라도 가까운 시일 내에 계속 구축하는 것보다 다루는 것이 좋습니다.

네트워크 파일 시스템

이 질문은 로컬 파일 시스템이있는 머신간에 파일을 전송하는 좁은 범위에 중점을 두어 머신 별 소유권 상태를 허용합니다.

네트워크 파일 시스템 고려 사항은 UID / GID 매핑을 동기화 상태로 유지하려는 가장 쉬운 경우입니다. 일반적으로 그림에 들어가는 순간 창에서 언급 한 "달리 달성"할 수 있기 때문입니다. 물론, 현재 호스트간에 네트워크 파일 시스템을 공유하지 않았을 수도 있습니다. 현재 호스트 또는 미래에 생성되는 호스트간에 네트워크 파일 시스템이 도입되지 않을 것이라고 정직하게 말할 수 있습니까? 그렇지 않다고 생각하는 것은 그리 앞선 생각이 아닙니다.

그 가정 /home에서 공유 네트워크 파일 시스템이다 host1host2하기 실시 예에서.

  • 동의하지 않는 권한 : /home/user1각 시스템의 다른 사용자가 소유합니다. 이를 통해 사용자는 시스템 전체에서 홈 디렉토리에 지속적으로 액세스하거나 수정할 수 없습니다.
  • chown wars : 사용자가 홈 디렉토리 권한을 특정 시스템에서 수정하도록 요청하는 티켓을 제출하는 것이 일반적입니다. 에이 문제를 해결하면에 host2대한 권한 이 중단됩니다 host1. 누군가가 물러서서 줄다리기가 진행되고 있음을 깨닫기 전에 이러한 티켓 중 일부가 작동해야 할 수도 있습니다. 유일한 해결책은 동의하지 않는 ID 매핑을 수정하는 것입니다. 어느 것이 ...
  • UID / GID 리 밸런싱 지옥 : ID 수정의 복잡성은 나중에 여러 컴퓨터에서 단일 사용자를 수정하는 데 필요한 재 매핑 횟수에 따라 기하 급수적 으로 증가 합니다. ( user1의 ID는 user2있지만 user2ID는 user17...이며 클러스터의 첫 번째 시스템 일뿐입니다.) 문제를 해결하기 위해 대기하는 시간이 길어질수록 체인이 더 복잡해져 여러 서버에서 응용 프로그램의 다운 타임이 종종 발생합니다. 동기화를 제대로하기 위해
  • 보안 문제 : user2host2같은 UID가 user1host1그들을 쓸 수 있도록 /home/user1에서 host2의 지식 없이도을 user1. 이러한 변경 사항은 host1의 권한으로 평가됩니다 user1. 무엇이 잘못 될 수 있습니까? (경우 user1앱 사용자는, 개발의 사람이 됩니다 그것을 쓰기의 발견 됩니다 변경합니다.이 한 번 입증 된 사실이다.)

다른 시나리오가 있으며 가장 일반적인 시나리오의 예일뿐입니다.

이름이 항상 옵션은 아닙니다

숫자 ID로 작성된 스크립트 또는 구성 파일은 본질적으로 사용자 환경 내에서 이식 할 수 없게됩니다. 일반적으로 문제가되지 않습니다. 대부분의 사람들은 반드시 필요한 경우가 아니면 이들을 하드 코딩하지 않습니다. 그러나 때로는 작업중인 도구로 문제를 선택할 수 없습니다. 이 시나리오에서는 유지 수밖에 N 스크립트 또는 구성 파일의 다른 버전.

예 : pam_succeed_if당신의 필드를 사용할 수 있습니다 user, uid그리고 gid...는 "그룹"옵션이 눈에 띄게 결석입니다. 여러 시스템이 그룹 기반 액세스 제한의 형태를 구현할 것으로 예상 된 위치에 넣어한다면, 당신은 할 것 N 팸의 CONFIGS의 다른 유사합니다. (또는 충돌을 피해야하는 최소한 하나의 GID)

중앙 집중식 관리

natxo의 대답은 이것에 꽤 잘 적용되었습니다.


네트워크 파일 시스템을 사용하면 다른 uid와 관련된 문제를 해결하지 못한다고 말하는 것이 옳지 않습니다. uid 맵을 지원하는 적어도 하나의 파일 시스템을 통해 다른 시스템에서 일치하는 그룹과 사용자를 지정할 수 있습니다.
Vality

@Vality 일반적으로 사용 가능한 솔루션 이었지만 여전히 확장 가능한 솔루션이라고 부릅니다.
Andrew B

동의합니다. OP가 불가능하다고 생각하기를 원하지 않았습니다. 최상의 솔루션이 동기화를 유지한다는 제안에 크게 동의합니다.
Vality

감사! 불행히도 "초기"는 오랫동안 사라졌습니다. 일부 ldap / kerberos 구성은 내가 일하는 곳에 여기에 포함시키고 싶은 것이지만 지금은 그렇지 않습니다. 다른 이유로 인해 상호 운용 시스템에서 UID / GID를 사용하는 데 특히 관심이있었습니다. 내가 말했듯이 파일 전송은 하나의 문제 (현재 "작동"상태 임)이므로 UID의 영향을받는 다른 것들이 있는지 알고 싶었습니다. 이러한 "다른 시나리오"의 키워드를 추가 할 수 있습니까? 이것이 훌륭한 답변이 될 것입니다!
alex

@alex 글쎄, 나는 네트워크 파일 시스템 문제의 관점에서 "다른 시나리오"를 의미했다. 게임이 늦어도 문제가 해결되지 않은 채 계속 악화됩니다. Google에서 제공 한 이유가 적절하지 않은 경우 "다른 이유"를 제공하여 질문을 조금 더 조정하면 도움이 될 것입니다. 지금까지 제공된 답변은 제 의견으로는 꽤 좋은 답변입니다. 당신이 경영진을 설득하려고한다면, 우리가 그들이 올바른 일을하도록하는 것은 아닙니다.
Andrew B

18

일단 특정 크기에 도달하면 (그리고 생각보다 빨리) 모든 호스트의 누군가에 대한 비밀번호 변경 또는 계정 비활성화는 PITA라는 것을 알게 될 것입니다. 이것이 바로 사람들이 openldap과 같은 LDAP 데이터베이스 (또는 NIS를 사용하지만 현재 안전하지는 않지만)를 사용하는 시스템을 사용하는 이유입니다.

모든 계정 / 그룹 정보를 중앙 데이터베이스에 유지하면 모든 호스트가 해당 정보를 공유합니다. 거기에서 더 많은 일을 할 수 있습니다 : 물론 파일 권한에 사용자 정보를 사용하고 사용자를 만들 필요없이 ldap 바인딩이있는 모든 응용 프로그램에 대한 가상 사용자를 만드십시오 (많은 웹 응용 프로그램에서 사용할 수 있음) 사용자 데이터베이스에 대한 ldap), 중앙 sudo 규칙 데이터베이스 유지, autofs 환경 배포, dns 영역 유지 ...

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.