Linux에서 기본 그룹 및 사용자 뒤에있는 이유


14

일반적인 Linux 배포판 (각각 ArchLinux 및 Debian)의 기본 사용자 및 그룹 관리를 살펴보면 두 가지 사항과 기본 설정 및 구성 수정의 결과에 대해 궁금합니다.

USERGROUPS_ENABin 의 기본값 /etc/login.defs은 "yes"인 것으로 보입니다. 이는 "기본적으로 새 사용자에 대해 그룹이 작성 됨"에 반영되어 새 사용자 가있을 수 있으므로 useradd새 사용자가 작성 될 때마다 그룹은 이름이 같고이 새로운 사용자만으로 생성됩니다. 그 용도가 있습니까? 아니면 단지 자리 표시 자입니까?

이렇게하면 사용자 / 그룹 / 다른 사람 으로서 권한 관리의 일부를 잃어버린 것 같습니다. 그룹 "users"또는 "regulars"또는 호출하려는 모든 것을 소유하지 않고 모든 사용자의 기본 그룹으로 만드는 것이 좋지 않습니까?

내 질문의 두 번째 부분은 여전히 ​​아치와 데비안에서 본 것을 기반으로합니다. 기본적으로 많은 사용자가 생성됩니다 (FTP, HTTP 등). 그것들에 대한 사용이 있습니까, 아니면 역사적 이유로 만 존재합니까?

나는 그것들을 제거하려고 생각하고 있지만 그것을 사용할 수있는 것을 깨뜨리고 싶지는 않지만 그렇게하는 것을 본 적이 없으며 무엇을 할 수 있는지 전혀 모른다. 내가 본 적이없는 기본 그룹 (tty, mem 등)도 마찬가지입니다.


시간을 좀 주시면 좋은 답변을 드리겠습니다. 나는 단지 느린 타입입니다. 30 분 이상일 수 있습니다.
eyoung100

이 모든 그룹의 주요 요점은 set-group-id 프로그램입니다.
Barmar

2
첫 번째 질문은 매우 가까운 이 하나 .
Leiaz

@ECarterYoung : 물론 시간을 내 주셔서 감사합니다!
Horgix

@Leiaz : "하지만"사용자 "또는"레귤러 "그룹을 갖는 것이 나쁘거나 모든 사용자를위한 기본 그룹 인 그룹을 갖는 것이 좋지 않습니까?" 부분적으로 소개하고 이전에 있던 것을 유지했습니다. 나는 주로 StackOverflow에 게시 했지만 여기로 지시되었습니다.
Horgix

답변:


13

사용자 당 그룹

나도 사용자 별 그룹에서 많은 유틸리티를 보지 못합니다. 주요 사용 사례는 사용자가 "친구"가 파일에 액세스 할 수 있도록하려는 경우 친구 사용자를 그룹에 추가 할 수 있다는 것입니다. 내가 본 시스템 중 실제로 이런 방식으로 사용하는 시스템은 거의 없습니다.

USERGROUPS_ENABin /etc/login.defs이 "no"로 설정 되면 useradd작성된 모든 사용자가 필드로 정의 된 그룹에 추가 /etc/default/useradd됩니다 GROUP. 대부분의 배포에서 이것은 100일반적으로 users그룹에 해당하는 GID로 설정됩니다 . 이를 통해보다 일반적인 사용자 관리가 가능합니다. 그런 다음보다 세밀한 제어가 필요한 경우 이러한 그룹을 수동으로 추가하고 적절한 그룹에 사용자를 추가 할 수 있습니다.

기본 생성 그룹

대부분은 역사적인 이유에서 비롯되었지만 오늘날에도 여전히 유효한 용도로 사용됩니다.

  • 디스크는 대부분의 디스크 드라이브 장치를 소유 한 그룹입니다
  • lp는 병렬 포트를 소유하며 때로는 컵에 대한 관리자 권한으로 구성됩니다.
  • uucp는 종종 직렬 포트 (USB 직렬 포트 포함)를 소유합니다.
  • CD 드라이브에 특권을 마운트하려면 cdrom이 필요합니다
  • 일부 시스템은 sudo 권한으로 wheel을 사용합니다. 일부는
  • 기타

다른 그룹은 백그라운드 스크립트에서 사용됩니다. 예를 들어, man임시 파일 등이 실행될 때 생성합니다. 해당 프로세스는 해당 파일 중 일부에 대해 man 그룹을 사용하며 일반적으로 자체 정리됩니다.


그러나 Linux Standard Base Core Specification 에 따르면 루트, bin 및 데몬 인 3 명의 사용자 만 필수 입니다. 다른 그룹 의 근거 는 다음과 같습니다.

선택적 사용자 및 그룹을 지정하는 목적은 응용 프로그램과 배포 사이의 이름 충돌 가능성을 줄이는 것입니다.

따라서 이러한 그룹을 유지하는 것이 더 나은 것처럼 보입니다. 그건 한다면 이론적 일부, "신비"일을하지 작업 오른쪽으로 시작할 수 있지만, 파손없이 제거 할 수 (당신이 등을 해당 그룹을 죽일 경우 예를 들어, 어떤 사람이 페이지가 렌더링되지 않음). 그것들을 거기에 두는 데 아무런 해를 끼치 지 않으며 일반적으로 모든 Linux 시스템에 해당 시스템이 있다고 가정합니다.


임시 파일을 생성하는 사람에 대한 자세한 내용은 어디에서 찾을 수 있습니까? man 페이지가 열리면 man ps aux | grep man그룹에서 실행중인 프로세스 find -group man /가 표시되지 않으며 아무 것도 표시되지 않습니다. 표준 Archlinux 설치에서 man 2.6.7.1로 시도했습니다.
Horgix

4

질문 1 : 동일한 사용자 및 그룹에 대한 추론

안녕하세요, 저는 ecyoung이고 당신은 horgix입니다. 우리는 매일 일하고 프로그래머와 동일한 Linux 서버에 로그인합니다. 얼마 전, 시스템 관리자는 사용자 생성 및 유지 관리를보다 쉽게하기로 결정했기 때문에 USERGROUPS_ENAB옵션을 끄고 기존 사용자를 모두 새 users그룹에 추가했습니다.


이렇게하면 모든 사용자가 다른 모든 사용자 파일에 액세스 할 수 있으므로 사용자 작성이 쉬워 지지만 유지 관리가되지 않습니다. 기업 환경에서 Sarbanes OxleySegregation of Duties 와 같은 이유로 큰 문제는 아닙니다 . 파일 A를 만들면 그룹 비트가 사용자 그룹으로 설정되어 모든 사용자가 최소한 파일 A를 읽을 수 있습니다. 시스템 관리자가 게으 르면 모든 사용자가 파일 A를 RW 할 수 있습니다. 이는 Sarbanes Oxley를 물리칩니다 별도의 부서가 다른 사람의 문서를 훨씬 적게 읽을 수 없어야하기 때문에 SoD.


ecyoung으로 문서를 만들면 사용자 / 그룹이 활성화 된 상태에서만 rwx 권한이 있습니다. 내 그룹에 다른 사람이 없기 때문에 내 문서를 열면 빈 페이지가 경고와 함께 표시됩니다. 이를 통해 Sarbanes-Oxley 및 SoD가 시행됩니다. 다른 사용자를 초대하면 해당 사용자는 rw 액세스 권한이 부여되며, 그렇게함으로써 본인이나 본인을 물기 위해 돌아 오는 것이 없다는 것을 알고 있습니다. 다른 사람들이 말했듯이 집에 있다면 분리가 중요하지 않을 수 있습니다. 이를 확인하면 옵션을 안전하게 해제 할 수 있으며 모든 사용자가 usersGID가 100 인 그룹에 추가 됩니다. 아래 질문 2를 참조하십시오.

가설 :
IT에서 일하고 Louis는 Payroll에서 일합니다. Louis는 세금 및 급여 시트를 홈 디렉토리에 보관하지만 둘 다 사용자 그룹에 있으므로 사용자에 대해 + r로 표시되고 스프레드 시트를 찾기 때문에 홈 디렉토리를 엽니 다. Joe 및 Fred와 함께 급여 금액이 표시됩니다. 당신은 조와 프레드가 당신이 그들의 월급을 알고 싶어한다고 생각합니까?


질문 2 : 그룹 ID는 0 ~ 500입니다.

그룹 ID 및 반대로 사용자 ID 0-500은 시스템 계정 및 장치 액세스 용으로 예약되어 있습니다. 표준 계정 목록은 사전 구성된 시스템 그룹 표 를 참조하십시오 . 이러한 계정을 직접 제거하지 마십시오. 예를 들어, 사용자 ftp를 제거하려면 패키지 관리 시스템으로 ftp 데몬을 제거하십시오. 그렇게하면 시스템 계정도 제거됩니다. 시스템 서비스에는 다음이 포함되지만 이에 국한되지 않습니다.

  • CUPS 인쇄 서비스
  • MySQL 서버 데몬
  • FTP 서버 데몬
  • Apace 웹 서버
  • 원격 연결을위한 X 서버 소켓
  • ALSA 사운드 시스템 데몬
  • DBUS 서비스

다른 독자가 있으므로 다른 독자가 위의 서비스 목록에서 추가하거나 제거하려는 경우 그렇게하십시오.


5
좋은 가상이지만 실패. 1. 기본 권한은 일반적으로 022로 표시되며 이는 다른 사람이 읽기 권한을 가짐을 의미합니다. 2. sysad는 일부 그룹에 모두를 할당하는 대신 부서에 따라 그룹을 생성하고 계정을 생성하는 동안 올바른 그룹을 할당해야하므로 게으르지 만 무능합니다. 는 USERGROUPS_ENAB다음 해제 상태를 유지해야한다. 사용 안함 USERGROUPS_ENAB! = 모든 사용자를 같은 그룹에 배치합니다.
muru

첫 번째 부분에 대한 @ECarterYound : 나는 당신이 액세스 보호에 대해 무엇을 의미하는지, 내가 틀렸다면 나를 수정하지만 users그룹의 모든 사용자가 그룹 에 대한 적절한 권한 관리에 문제가되어서는 안됩니다. 소유자보다 그룹에 대한 권리. 따라서 USERGROUPS_ENAB다른 사용자가 액세스를 제한하면서 파일과 디렉토리를 만들 때 기본 권한을 유지할 수 있으므로 유지 관리가 더 쉬워집니다.
Horgix

맞습니다. 그러나 많은 사람들이 개인 사용자 인 경우 그룹을 올바르게 관리하지 않습니다. 확실하게 확인할 수는 없지만 관리자는 권한 관리를 강화하기 위해 옵션을 만들었습니다.
eyoung100

3

예전과 같이 모두 기본 그룹을 공유하는 경우 그룹을 차단하려면 umask를 077로 설정해야합니다. 기본값이 나이면 umask를 027로 설정할 수 있습니다. 이제 파일 디렉토리를 공유 그룹으로 설정하면이 그룹을 읽을 수 있습니다. 모드를 망칠 필요가 없습니다.

이것은 하나의 예일 뿐이지 만 일반적으로 그룹을 켜고 관리하기 쉽도록 필요할 때까지 그룹을 비활성화하는 방법입니다.


1

사용자 별 그룹을 사용하면 "홈 디렉토리의 개인 정보 보호"와 "공유 폴더의 간편한 공동 작업"을 모두 가질 수 있습니다. 사용자 별 그룹이 없으면 둘 중 하나만 가질 수 있습니다. 세부 사항은 다음과 같습니다.

Unix는 회사 파일 서버이든 2 명의 사용자가있는 PC이든 다중 사용자 시스템입니다. "홈 디렉토리의 개인 정보 보호"는 여러 가지 방법으로 실현 될 수 있습니다.

"umask 077"을 설정하면 파일은 rw로 만들어지고 다른 사람에게는 권한이 없습니다. 또는 027 또는 022를 사용하여 일부 또는 모두가 파일을 읽을 수는 있지만 쓸 수는 없습니다. 명백한 단점은 공유 폴더에서 공동 작업을 할 수 없다는 것입니다. 다른 사용자는 엄격한 권한으로 인해 자신이 만든 파일에서 작업 할 수 없기 때문입니다. 이러한 파일에 대한 권한을 변경할 수 있지만 "너무 많은 작업"이며 종종 잊혀집니다.

공동 작업을하려면 "umask 7"과 같은 것을 원하므로 본인과 소유 그룹 모두 자신이 만든 파일을 읽고 쓸 수 있습니다. 공유 액세스가 필요한 모든 사람으로 구성된 공유 폴더 및 그룹에 유용합니다. 그러나 홈 폴더의 개인 정보를 잃어 버렸습니다!

사용자 별 그룹이 솔루션입니다! umask 7을 사용하므로 모든 파일은 "rw, 그룹은 rw"가됩니다. 홈 디렉토리의 파일은 개인 그룹과 함께 "소유 그룹"으로 작성되므로 "group rw"권한에도 불구하고 다른 사람이 해당 파일에 액세스 할 수 없습니다. 특정 그룹에 속한 사람은 아무도 없기 때문입니다.

공유 폴더에서 계속 협업 할 수 있습니다. 공유 폴더의 파일은 소유 그룹에 대해 "rw"가되고 sysadmin은 공유 그룹 (공동 자라고 함)이 파일의 그룹 소유자가되도록 공유 폴더를 설정합니다. 모든 공동 작업 사용자를 구성원으로하여이 공동 작업자 그룹을 작성하면됩니다. 그런 다음 관리자는 공유 폴더의 그룹 소유권을 "협업 자"로 설정하고 공유 폴더에 대한 SETGID 권한을 설정합니다. SETGID를 켜면 공유 폴더에서 작성된 항목은 공유 폴더와 동일한 그룹 소유자, 즉 "협업 자"그룹을 갖게됩니다. 그리고 umask 7 (또는 2)을 사용하면이 그룹의 사람들은 모두 읽기 + 쓰기 권한을 가지므로 공동 작업 할 수 있습니다.


0

원래 Unix 프로세스는 한 번에 하나의 그룹에 속할 수있었습니다 (의 이전 chgrp(1)비밀번호 필드에 저장된 그룹 비밀번호를 요청 하는 명령 이었음 /etc/groups). 플러스 시스템은 긴밀한 사용자 그룹이 사용했습니다. users그룹의 모든 사용자를 보유 하고 그룹 권한으로 시스템 전체에서 자료를 공유하는 것이 합리적 입니다. 실제 보안 의식이 없으며 수십 명의 동료 사용자가 거의 의심하지 않습니다. 모든 기계가 같은 기계에있었습니다. 블로그 등을 통해 물건을 공유 할 네트워크가 없습니다.

오늘날 유닉스 시스템에는 수백 명의 사용자가 있으며 보안 요구 사항이 더 엄격하며 사용자 (및 프로세스)는 여러 그룹에 속할 수 있습니다. (더 우둔한) 사용자에게 홈 그룹을 제공하고 공유를 위해 길을 잃도록 허용하십시오. 또는 ACL을 사용하십시오.

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