동일한 UID를 가진 여러 * NIX 계정

표준 예상 동작이 있는지와 동일한 UID를 가진 Linux / Unix에서 둘 이상의 계정을 만들 때 이것이 나쁜 습관으로 간주되는지 궁금합니다. 나는 이것을 사용하여 RHEL5에 대한 테스트를 수행했으며 예상대로 작동했지만이 트릭을 사용하여 운명을 유혹하는지 알 수 없습니다.

예를 들어, 동일한 ID를 가진 두 개의 계정이 있다고 가정 해 보겠습니다.

a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash

이것이 의미하는 것은 :

• 자체 비밀번호를 사용하여 각 계정에 로그인 할 수 있습니다.
• 내가 만든 파일은 동일한 UID를 갖습니다.
• "ls -l"과 같은 도구는 UID를 파일의 첫 번째 항목 (이 경우 a1)으로 나열합니다.
• 두 계정 간에는 실제로 동일한 사용자이므로 권한 또는 소유권 문제가 발생하지 않습니다.
• 각 계정에 대한 로그인 감사를 받으므로 시스템에서 발생하는 상황을 추적하는 데 더 세분화됩니다.

그래서 내 질문은 :

• 이 능력이 설계 되었습니까, 아니면 그것이 작동하는 방식입니까?
• 이것이 * nix 변형에서 일관됩니까?
• 이것이 받아 들여 지는가?
• 이 관행에 의도하지 않은 결과가 있습니까?

여기서 아이디어는 일반 사용자 계정이 아닌 시스템 계정에 사용하는 것입니다.

내 의견 :

이 능력이 설계 되었습니까, 아니면 그것이 작동하는 방식입니까?

설계되었습니다. * NIX를 사용하기 시작한 후 사용자를 공통 그룹에 배치 할 수있었습니다. 문제없이 UID를 동일하게 유지하는 기능은 모든 것처럼 잘못 관리 될 경우 문제를 일으킬 수있는 의도 된 결과 일뿐입니다.

이것이 * nix 변형에서 일관됩니까?

나는 그렇게 믿는다.

이것이 받아 들여 지는가?

일반적으로 사용되는 방식으로 허용됩니다.

이 관행에 의도하지 않은 결과가 있습니까?

로그인 감사 외에는 아무것도 없습니다. 정확히 원하지 않는 한, 시작하십시오.

모든 유닉스에서 작동합니까? 예.

사용하기에 좋은 기술입니까? 더 나은 다른 기술이 있습니다. 예를 들어, 유닉스 그룹과 엄격하게 제어 된 "스도"구성을 올바르게 사용하면 같은 결과를 얻을 수 있습니다.

나는 이것이 문제없이 사용 된 곳을 정확히 보았습니다. FreeBSD에서는 기본 쉘로 / bin / sh를 가진 "toor"(루트 철자법)라는 두 번째 루트 계정을 만드는 것이 일반적입니다. 이 방법으로 루트 쉘이 엉망이 되어도 로그인 할 수 있습니다.

귀하의 질문에 정식 답변을 제공 할 수는 없지만 일명 우리 회사는 루트 사용자와 함께 수년 동안이 일을 해 왔으며 아무런 문제가 없었습니다. 유일하게 존재하는 이유는 / bin / sh 또는 bin / bash 대신 쉘로 / bin / ksh를 갖는 'kroot'사용자 (UID 0)를 작성합니다. Oracle DBA는 설치마다 3 ~ 4 개의 사용자 이름을 가진 동일한 사용자 ID를 가진 사용자와 유사한 작업을 수행한다는 것을 알고 있습니다. 솔라리스와 리눅스에서 10 년이 걸렸습니다.

일반 사용자 계정으로는이 작업을 수행하지 않습니다. 언급했듯이 초기 로그인 후 모든 것이 로그 파일의 이름으로 돌아가므로 한 사용자의 작업이 다른 사용자의 작업으로 로그에 가장 될 수 있다고 생각합니다. 시스템 계정의 경우 훌륭하게 작동합니다.

이 능력이 설계 되었습니까, 아니면 그것이 작동하는 방식입니까?

그런 식으로 설계되었습니다.

이것이 * nix 변형에서 일관됩니까?

그렇습니다.

이것이 받아 들여 지는가?

무슨 뜻인지에 따라 다릅니다. 이 유형의 것은 매우 특정한 문제에 대한 답변입니다 (루트 / 투어 계정 참조). 다른 곳에서는 미래에 바보 같은 문제를 요구하고 있습니다. 이것이 올바른 해결책인지 확실하지 않으면 아마도 아닐 것입니다.

이 관행에 의도하지 않은 결과가 있습니까?

사용자 이름과 UID를 상호 교환 가능한 것으로 취급하는 것이 일반적입니다. 다른 사람들이 지적했듯이 로그인 / 활동 감사는 정확하지 않습니다. 또한 관련 사용자 관련 스크립트 / 프로그램 (distro의 useradd, usermod, userdel 스크립트,주기적인 유지 보수 스크립트 등)의 동작을 검토하고 싶을 것입니다.

이 두 사용자를 새 그룹에 추가하고 해당 그룹에 필요한 권한을 부여하여 달성 할 수없는 목표는 무엇입니까?

이 관행에 의도하지 않은 결과가 있습니까?

내가 아는 한 가지 문제가 있습니다. Cron은이 UID 앨리어싱에서 잘 작동하지 않습니다. Python 스크립트에서 "crontab -i"를 실행하여 cron 항목을 업데이트하십시오. 그런 다음 쉘에서 "crontab -e"를 실행하여 동일하게 수정하십시오.

이제 cron (vixie, 내 생각에)은 a1과 a2 (/ var / spool / cron / a1 및 / var / spool / cron / a2)에 대해 동일한 항목을 업데이트했습니다.

이것은 내가 본 모든 배포판에서 예상되는 동작이며 '적'이 루트 액세스 권한을 가진 계정을 숨기는 데 사용하는 일반적인 트릭입니다.

확실히 표준은 아니지만 (어디서나 보지 못했지만) 자신의 환경에서 적합하다고 볼 수없는 이유는 없어야합니다.

지금 당장 염두에 두어야 할 것은 감사가 어려워 질 수 있다는 것입니다. 동일한 uid / gid를 가진 두 명의 사용자가있는 경우 로그를 분석 할 때 어떤 작업을 수행했는지 파악하기가 어려울 것입니다.

기본 그룹 ID를 공유하는 것이 일반적이므로 질문은 실제로 UID와 관련이 있습니다.

나는 루트 암호를 밝힐 필요없이 누군가에게 루트 액세스 권한을 부여하기 전에이 작업을 수행했습니다. (sudo가 더 나은 선택 이었지만, 나는 생각한다)

내가 조심해야 할 가장 중요한 것은 사용자 중 하나를 삭제하는 것과 같은 것입니다. 프로그램 이 혼동되어 두 사용자 또는 둘 다에 속하는 파일 또는 이와 유사한 것들이 삭제 될 수 있습니다 .

실제로 프로그래머는 아마도 사용자와 UID 사이에 1 : 1 관계 가 있다고 가정 하므로 userdel에 대해 설명한 것과 비슷한 다른 프로그램에서 예기치 않은 결과가 발생할 수 있습니다.

BTW-이 질문 / 답변은 오늘 OS에 맞게 업데이트되었습니다.

redhat 에서 인용 : 고유 한 UID 및 GID 번호 할당 관리, UID 및 GID 사용법 및 관리 및 생성기 (ID 서버) 방법에 대해 설명합니다.

임의의 UID 및 GID 값을 생성하고 동시에 복제본이 동일한 UID 또는 GID 값을 생성하지 않도록해야합니다. 단일 조직에 여러 개의 서로 다른 도메인이있는 경우 고유 한 UID 및 GID 번호가 IdM 도메인을 가로 질러야 할 수도 있습니다.

마찬가지로 시스템에 대한 액세스를 허용하는 유틸리티는 예기치 않게 작동 할 수 있습니다 (동일한 참조).

두 항목에 동일한 ID 번호가 할당되면 해당 번호를 검색 할 때 첫 번째 항목 만 반환됩니다.

"첫 번째"개념이 잘못 정의되면 문제가 발생합니다. 설치된 서비스에 따라 사용자 이름이 가변적 인 해시로 유지되어 일관성없는 요소에 따라 다른 사용자 이름을 반환 할 수 있습니다. (나는 때때로 하나의 ID로 2 개의 사용자 이름을 사용하려고 시도했기 때문에 이것이 사실이라는 것을 알고 있습니다. 하나는 로컬 사용자 이름이고 다른 하나는 UID에 매핑하려는 도메인입니다. 완전히 다른 방법으로)하지만 "usera"로 로그인하여 "who"또는 "id"를 수행하고 "userb"또는 "usera"를 임의로 볼 수 있습니다.

그룹에서 여러 UID 값을 검색하기위한 인터페이스가 있지만 (단일 GID를 가진 그룹은 여러 UID와 연결되도록 설계됨) 하나의 UID에 대한 이름 목록을 반환 할 수있는 이식 가능한 인터페이스가 없으므로 동일한 기대 또는 동일한 시스템의 시스템 또는 응용 프로그램 간의 유사한 동작이 불행하게도 놀라게 될 수 있습니다.

Sun (현재 oracle) yp (yellowpages) 또는 NIS (NetworkInformationServices)에는 고유성 요구 사항에 대한 참조가 많이 있습니다. 특수 기능 및 서버는 여러 서버 및 도메인에 고유 한 ID 를 할당하도록 설정됩니다 (예 : uid_allocd, gid_allocd-UID 및 GID 할당 자 데몬 맨 페이지

세 번째 소스는 NFS 계정 매핑에 대한 Microsoft의 서버 설명서입니다. NFS는 유닉스 파일 공유 프로토콜이며 ID에 의해 파일 권한 및 액세스가 유지되는 방법을 설명합니다. 그들은 다음과 같이 씁니다.

• UID. 이것은 UNIX 운영 체제에서 사용자를 식별하기 위해 사용하는 부호없는 정수이며 passwd 파일에서 고유해야합니다.

• GID. 이것은 UNIX 커널이 그룹을 식별하기 위해 사용하는 부호없는 정수이며 그룹 파일에서 고유해야합니다. MS-NFS 관리 페이지

일부 OS는 여러 이름 / UID (BSD 파생어, 아마도?)를 허용했을 수도 있지만 대부분의 OS는이 고유 한 특성에 의존하며 그렇지 않은 경우 예기치 않게 작동 할 수 있습니다.

참고-이 날짜가 지난 항목을 고유하지 않은 UID / GID를 수용하는 최신 유틸리티에 대한 지원이라고 언급 했으므로이 페이지를 추가하고 있습니다.

나는 그것이 좋은 아이디어인지 아닌지 모르겠지만, 위의 행동을 몇 곳에서 사용합니다. 대부분 ftp / sftp 서버에 액세스하고 웹 사이트 컨텐츠를 업데이트하는 데 사용되는 계정을위한 것입니다. 아무 것도 깨지 않는 것 같고 여러 계정을 사용했을 때보 다 쉽게 권한을 처리하는 것처럼 보였습니다.

동일한 UID를 가진 여러 계정을 사용하여 발생하는 (모호하지 않은) 문제에 부딪 쳤으며 이것이 왜 좋은 습관이 아닌지에 대한 예시로 공유하겠다고 생각했습니다.

필자의 경우 공급 업체는 RHEL 7에 Informix 데이터베이스 서버 및 웹 애플리케이션 서버를 설정했습니다. 설정 중에 UID 0을 사용하는 여러 "루트"계정이 작성되었습니다 (이유는 묻지 않음). 즉, "root", "user1"및 "user2"는 모두 UID 0입니다.

RHEL 7 서버는 나중에 winbind를 사용하여 Active Directory 도메인에 가입했습니다. 이 시점에서 Informix DB 서버를 더 이상 시작할 수 없습니다. oninit오류 메시지와 함께 실행 이 실패했습니다 "Must be a DBSA to run this program".

문제를 해결하는 동안 발견 한 내용은 다음과 같습니다.

1. Active Directory 가입 시스템 에서 id root또는 getent passwd 0(UID 0을 사용자 이름으로 확인하기 위해) 실행 하면 "root"대신 "user1"또는 "user2"가 임의로 반환됩니다.

2. Informix는 시작하는 사용자의 텍스트 사용자 이름이 "루트"인지 여부를 확인하기 위해 문자열 비교에 의존하고 있었으며 그렇지 않은 경우 실패했습니다.

3. winbind를하지 않고, id root그리고 getent passwd 0지속적으로 사용자 이름으로 "루트"를 반환합니다.

수정 사항은 다음에서 캐싱 및 지속성을 비활성화하는 것입니다 /etc/nscd.conf.

enable-cache    passwd      no
persistent      passwd      no

이 변경 후 UID 0이 다시 한번 "루트"로 해석되어 Informix를 시작할 수 있습니다.

이것이 누군가에게 도움이되기를 바랍니다.