리눅스에서 모든 작은 일에 대해 '스도'를 쓰지 않아도되는 방법이 있습니까?


59

곧 상당한 양의 PHP 작업을 할 예정이며 RoR 학습에 관심이 있으므로 VirtualBox에 Linux Mint 12를 설치했습니다.

지금까지 스위치의 가장 실망스러운 부분은 Linux 권한을 다루고 있습니다. sudo를 통해 루트로 위장하지 않고 유용한 다운로드를 할 수없는 것 같습니다 (예 : Symfony2 tarball을 다운로드 디렉토리에서 내 문서 루트로 복사하여 추출).

리눅스가 단순히 모든 권한을 열지 않고도 특정 디렉토리에 자유롭게 액세스 할 수 있도록 쉬운 방법이 있습니까?


1
많은 distirubution에는 다양한 시스템 유틸리티의 구성을 편집 할 수있는 그룹이 있습니다. 그 그룹에 자신을 넣고 새로운 껍질을 엽니 다.
dmckee

대신 홈 루트의 문서 루트를 문서 루트로 지정하는 것이 더 좋습니까?

3
'sudo'는 새로운 Linux 사용자가 너무 자주 사용하고 남용하는 말도 안되는 명령 중 하나입니다. 종종 웹에서 15 개의 명령이 sudo를 사용하는 자습서를 볼 수 있습니까? 일반적인 상황에서는 일반 사용자로 로그온하는 동안 특별한 권한이 필요하지 않습니다 (권장). 나는 그들이 사용했던 모든 것이 sudo를 사용하는 회사에있었습니다. 보안상의 이유로 금지를 시도했을 때, 그들은 불평했습니다. 암호 sudo 설정 파일을 조사한 후, 나는 그 정규 사용자로부터 시스템을 '루팅'할 수있는 결함 (항상 그러 했음)을 보았다. Sudo는 매우 위험하다!!
Jeach

답변:


77

두 가지 옵션이 생각납니다.

  1. 다음을 사용하여 원하는 디렉토리를 소유하십시오 chown.

    sudo chown your_username directory 
    

    (your_username을 사용자 이름으로 바꾸고 원하는 디렉토리로 디렉토리를 바꾸십시오.)

  2. 당신이 할 수있는 다른 일은 당신이하고있는 것을 알고있는 한 근본으로 일하는 것 입니다. 루트를 사용하려면 :

    sudo -s
    

    그런 다음 sudo모든 명령 을 입력 하기 전에 아무 것도 할 수 없습니다 .


"여러분이 할 수있는 일을 아는 한, 루트로 일하는 것입니다. 루트를 사용하려면 ..." -배포판과 보안 커뮤니티가 사용자에게 가르치려고했던 모범 사례를 취소합니다. 관련 : "최소 권한의 원칙이 무엇인지" .

16

일반적으로 시스템 전체에 영향을 미치지 않는 한 항상 자신의 사용자로 작업하십시오.

웹 서버에 저장하려는 파일이있는 경우 자신의 사용자로 작업 한 다음 sudo파일 시스템의 웹 제공 영역에 파일을 놓으십시오. 일반적으로 설치 스크립트에 의해 수행되며 sudo -u webmaster install-webserver-files, 또는 더 나은 sudo -u webmaster git update(또는 선택한 버전 제어 시스템) 과 같은 것을 실행합니다 .

개발 서버에서 작업 중이고 파일에 즉시 액세스 할 수있게하려면 웹 서버 영역에 디렉토리를 작성하고 소유하거나 최소한 쓸 수 있도록하십시오. 일회성 작업 ( sudo chown …또는 sudo -u webmaster setfacl …) 후에는 일상적인 작업에 대한 높은 권한이 필요하지 않습니다.

여러 사용자가 디렉토리에 쓰도록 허용하거나 소유자 이외의 여러 사용자 또는 여러 그룹에 대해 다른 권한을 갖는 것이 편리한 경우가 있습니다. 액세스 제어 목록 은이 기능을 제공합니다. 참조 서버의 공유 디렉토리 권한 문제 또는 백업 스크립트 권한 문제 .


3

예, 수퍼 유저 액세스 제어를 제공하는 루트로 로그인하십시오.
Windows에서와 동일한 개념으로 관리자를 사용하여 터미널에 로그인 할 수 있습니다.


나는 당신이 원래 포스터의 질문에 직접 대답하고 있음을 알고 있습니다. 그러나 이것은 좋지 않은 조언입니다.
bignose

당신은 Windows와 관련이 있습니다.
LeWoody

3

그것은 항상 내 이념으로, 사용자는 Linux에서 원하는 모든 것을 할 수 있고 다른 모든 것을 위해 항상 존재한다는 사실을 알고 sudo있습니다. 시스템 관리 sudo와 같은 경우가 많지만 다른 사용자는 거의 수행 할 수 없습니다 root. sudo(루트) 사용자로서 일부 일상적인 작업 및 권한을 다른 사람에게 위임하고 권한을 필요 이상으로 향상시키지 않으면 서 내 시간 및 다른 사람을 더 잘 관리하는 데 도움이되는 더 큰 이점이되었습니다. 동시에, 자신의 출품작을sudoers구성 파일. 관련이 있는지 확실하지 않지만 sudo는 신뢰할 수있는 권한으로 누구와 무엇을 할 수 있는지에 대한 더 나은 보안 관점을 제공합니다. 문제가 발생하더라도 책임을집니다. (나는 항상 범인을 찾기 위해 sudoers 로그 정보로 부적절한 피크를 수행 할 수 있습니다). 필자는 항상 Linux 환경에서 높은 권한으로 수행하려는 모든 작업에 sudo를 입력해야한다는 우려를 표명했습니다. 여기서도 같은 질문을 찾았습니다.

솔루션과 대안을 찾기위한 나의 탐구를보기 위해, 나는 리소스 기반 액세스 제어를 RBAC 보았지만 Solaris도구와 같은 다른 모험의 나라에서 나왔습니다 pfexec.이 접근 방식은 사용자의 권한을 이미 높이고 신뢰할 수 있기 때문에 더 좋습니다. sysadmins가 자신의 권한으로 수행하고자하는 일에 대한 양심과 경계에 대해

RBAC의 사용 가능한 솔루션과 Linux 세계에서의 구현을 고려할 때 나는 우연히 만났다.

SELinux http://www.ibm.com/developerworks/linux/library/l-rbac-selinux/

grsecurity http://en.wikipedia.org/wiki/Grsecurity

다른 구현이 있지만 목록의 최상위 순서로 고려할 것입니다. RBAC를 구현하는 것은 조직에서 특히 많은 사용자가있는 경우 많은 작업입니다. RBAC는 동종 환경에서 더 큰 솔루션을 제공합니다. 그러나 네트워크에 이기종 Unix 설치가 있고 사용자 데이터베이스가 공통 인 경우 실패 할 수 있습니다. SELinux는 Solaris에서 확장 / 구현되지 않으므로 RBAC / pfexec 도구는 Linux에서 구현되지 않습니다. 단일 작업을 수행하기위한 다양한 접근 방식이 있습니다. 예를 들면 다음과 같습니다. http://blogs.oracle.com/darren/entry/opensolaris_rbac_vs_sudo_howto

sudoers가 단일 호스트 방식이거나 네트워크 / 도메인에서 중앙 집중식 구성이 불가능한 것처럼 네트워크 전체의 다른 설치는이 방식 (openrbac를 일반적인 구현 방식으로 간주 할 수 있음)을 지원하지 않을 수 있습니다./etc/sudoers변경이있을 때마다 동기화해야합니다. 또한 sudoers 파일을 조작하는 동안 지식 기반 요구 사항이 있으므로 실수하지 않고 권한 부여를 허용하려면 sudoers 구성의 정책 언어를 이해해야합니다. RBAC는 중앙 집중식 접근 방식을 제공 할 수 있지만 보안 프로파일은 공통적 일 수 있지만, 부여 된 역할에서 사용자를 추가 / 제거하는 것은 단일 장소 (사용자 / 암호 / 그룹 정보가 저장되는 장소)에서 수행 될 수 있습니다. LDAP, NIS 또는 AD와 같은 도메인). 또한 smexec, smmultiuser와 같은 RBAC 데이터베이스에서 작동하는 데 필요한 명령을 거의 이해하지 않아도됩니다.

Sudo는 setuid 기능을 제공하는 모든 Unix / 유사 플랫폼에서 작동한다는 점에서 더 많은 플랫폼 간 접근 방식을 제공 할 수 있습니다. 모두 sudoRBAC루트가 아닌 사용자 수는주고 함께 할 수있는 권한 부여에 성공 root비밀번호 자체를. Sudo는 명령을 실행하는 동안 사용할 수있는 명령 행 인수에 대해보다 세밀한 / 세분화 된 접근 방식을 제공 할 수 있으며 인수가있는 명령을 승격 된 권한으로 실행할 수있는 명령으로 만 제한 할 수 있습니다. RBAC는 설치된 명령이나 이진 파일까지만 사용하도록 제한 할 수 있지만 명령 줄 인수는 제어 할 수 없습니다. RBAC 환경에서 감사 기능이 훨씬 우수하고 기본적으로 제공됩니다.sudo, 그것은 쉘에 부여하지 않는 것과 같이 취해진 보안 제약과 구성에 달려 있습니다. 이것들은 내가 인용 할 수있는 차이점 중 일부이며 RBAC보다 sudo를 사용하는 경향이 있지만, 한계가 있지만 해결 방법을 구현할 수는 있습니다. RBAC가 모든 문제를 해결하여 sudo의 이점을 향상시킬 때까지 sudo가 간단하다고 생각하지 않습니다.


1

작업중 인 문서 루트를 숨길 수 있으므로 모든 액세스 권한을 갖습니다.

Gem을 설치할 때마다 sudo를 입력하지 않으려면 다음 기사를 따르십시오. http://forums.site5.com/showthread.php?t=11954

또한 Ruby 및 Rails 버전을 관리하려면 RVM을 설치하는 것이 좋습니다. http://beginrescueend.com/

개발 한 버전과 다른 버전을 사용하여 앱을 배포하려는 호스트를 찾을 때 인생이 훨씬 쉬워집니다.


rvm에 대해 알고 있지만 포럼 링크에 감사드립니다.
주요 프로덕션

0

명령을 실행하십시오.

sudo su root

이제 루트 사용자로서 명령을 실행할 수 있습니다. 조심해! 실행되는 모든 명령은 루트 사용자입니다. 조심하지 않으면 일을 심각하게 망칠 수 있습니다.

또는 사용자가 파일을 저장하고 편집 할 수 있도록 디렉토리의 권한을 변경합니다.


4
왜 안돼 sudo -s?
sarnold

1
또는 sudo -i로그인 쉘로 시뮬레이트됩니다. sudo를 통해 bash 또는 다른 쉘을 실행하는 것보다 기본 로컬 루트 로그인에 약간 더 가깝습니다.
Bastian Ebeling

1
왜 안돼 su? sudo에 대한이 집착은 무엇입니까? 당신은 sudo가 필요하지 않습니다. 이제까지.
오리온

2
afaik, su루트 암호를 모르는 경우 에만 사용할 수 없습니다. 사용자를 sudoers에 추가하고 실행 sudo su하면 사용자가 기존의 알려진 사용자 비밀번호를 사용하여 에스컬레이션 할 수 있습니다.
Luke

0

/ etc / passwd 파일을 편집하고 사용자 및 그룹 ID를 UID 0 및 GID 0으로 변경하여 사용자 "yourUserName"에 루트 권한을 부여하십시오.

yourUserName : 0 : 0 :: / home / yourUserName : / bin / sh


2
보안 악몽을 권장하지 마십시오! 이것은 최악의 연습입니다.
카운터 모드

다른 사용자 계정이없고 내 홈 네트워크에 연결된 라즈베리 파이에이 솔루션을 사용하고 있습니다
Ufuk özkanlı

0

다른 답변에서 알 수 있듯이 가장 깨끗한 솔루션은 액세스 해야하는 파일과 디렉토리의 소유권을 변경하는 것입니다. 또는 새 전용 그룹을 작성하고 파일 및 디렉토리의 그룹 소유권을이 그룹으로 변경하고 이러한 파일 및 디렉토리에 대한 그룹 쓰기 권한을 설정할 수 있습니다. 마지막으로, 새 파일을 작성하는 경우 포함하는 디렉토리 (예 : 전용 그룹)의 그룹 소유권을 상속하도록 디렉토리에 SGID 비트를 설정하십시오.


-1

user @ server : ~ $ sudo passwd root
사용자의 [sudo] 비밀번호 :
새 UNIX 비밀번호 입력 :
새 UNIX 비밀번호 재 입력 :
passwd : 비밀번호가 성공적으로 업데이트되었습니다
user @ server : ~ $ su
비밀번호 :
root @ server : / home / user #

그 "#"프롬프트가 아름다움이 아닌가?

"스도"를 한 번만 사용하여

user @ server : ~ $ su
비밀번호 :
root @ server : / home / user #

서버 수명 동안.

다시 안전하게하기 위해

root @ server : / home / user # exit
exit
user @ server : ~ $

Sysadmins는 "sudo"가 mollycoddling 트렌드의 일부가 아닌 몇 년 동안이 작업을 해왔습니다.

이렇게하면 내 것이 아니라 돌보는 것이 당신의 책임입니다.

이안


얼마나 바이올린. 시도하십시오 sudo -s. 작업 완료
roaima
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.