mount에 루트 권한이 필요한 이유는 무엇입니까?

Linux에서 마운트하기 위해 사용자가 마운트 / 루트 당 sudo / 특정 적으로 권한을 부여해야하는 이유는 무엇입니까? 사용자가 무언가를 마운트 할 수 있는지 여부는 소스 볼륨 / 네트워크 공유 및 마운트 지점에 대한 액세스 권한을 기반으로 결정해야합니다. 비 루트 마운트의 두 가지 용도는 파일 시스템 이미지를 사용자 소유 방향으로 마운트하고 네트워크 공유를 사용자 소유 디렉토리에 마운트하는 것입니다. 사용자가 마운트 방정식의 양쪽을 제어 할 수 있다면 모든 것이 시원해야합니다.

접근 제한의 명확화 :

사용자가 소유 한 마운트 포인트에 액세스 할 수있는 모든 것을 마운트 할 수 있어야한다고 생각합니다.

예를 들어, 내 컴퓨터에서 / dev / sda1은 권한이있는 사용자 루트 및 그룹 디스크가 소유합니다 brw-rw----. 따라서 루트가 아닌 사용자는 / dev / sda1을 엉망으로 만들 수 없으며 마운트를 허용하지 않아야합니다. 그러나 사용자가 /home/my_user/my_imagefile.img 및 마운트 지점 / home / my_user / my_image /를 소유 한 경우 다음을 사용하여 해당 마운트 지점에 해당 이미지 파일을 마운트 할 수없는 이유는 무엇입니까?

mount /home/my_user/my_imagefile.img /home/my_user/my_image/ -o loop

Kormac이 지적했듯이 suid 문제가 있습니다. 따라서 suid가 잠재적으로 다른 문제가되는 것을 방지하기 위해 일부 제한을 추가해야합니다. 아마도 이것을 수행하는 한 가지 방법은 OS가 모든 파일을 마운트를 수행 한 사용자의 것으로 취급하게하는 것입니다. 그러나 간단한 읽기 / 쓰기 / 실행의 경우 이것이 왜 문제가되는지 알 수 없습니다.

사용 사례 :

실험실 공간이 8GB로 제한된 실험실에 계정이 있습니다. 이것은 작고 매우 성가시다. 필자는 개인 서버에서 nfs 볼륨을 마운트하여 기본적으로 사용 가능한 공간을 늘리고 싶습니다. 그러나 리눅스는 그런 것들을 허용하지 않기 때문에 나는 scp'ing 파일을 8GB 한도 이하로 유지하기 위해 계속 붙어 있습니다.

그것은 역사적 및 보안 제한 사항입니다.

역사적으로 대부분의 드라이브는 제거 할 수 없었습니다. 따라서 합법적 인 물리적 액세스 권한을 가진 사람으로의 마운트를 제한하는 것이 합리적이고 루트 계정에 액세스 할 수 있습니다. fstab 항목을 사용하면 관리자는 이동식 드라이브를 위해 다른 사용자에게 마운트를 위임 할 수 있습니다.

보안 관점에서 임의의 사용자가 임의의 위치에 임의의 블록 장치 또는 파일 시스템 이미지를 마운트 할 수있게하는 데는 세 가지 주요 문제가 있습니다.

• 소유하지 않은 위치에 마운트하면 해당 위치의 파일이 어두워집니다. 예를 들어 /etc, /etc/shadow알고있는 루트 암호를 포함 하여 원하는 파일 시스템을에 마운트하십시오 . 이것은 사용자가 자신이 소유 한 디렉토리에만 파일 시스템을 마운트 할 수있게하여 해결됩니다.
• 파일 시스템 드라이버는 종종 잘못된 파일 시스템으로 철저하게 테스트되지 않았습니다. 버그가있는 파일 시스템 드라이버를 사용하면 잘못된 파일 시스템을 제공하는 사용자가 코드를 커널에 삽입 할 수 있습니다.
• 파일 시스템을 마운트하면 마운터가 일부 파일에서 다른 방법으로 작성 권한이없는 것처럼 보이게 할 수 있습니다. setuid를 실행 및 장치 파일은 가장 확실한 예입니다, 그리고 그들은에 의해 고정 nosuid하고 nodev필요에 의해 암시되는 옵션 user에 /etc/fstab.
  지금까지 시행 user할 때mount루트에 의해 호출되지 않습니다. 그러나 더 일반적으로 다른 사용자가 소유 한 파일을 생성 할 수있는 것은 문제가됩니다. 해당 파일의 내용은 마운터 대신 소유권이있는 소유자에 의한 것으로 간주됩니다. 루트에 의해 다른 파일 시스템으로 속성을 보존하는 일반적인 사본은 선언되었지만 관련되지 않은 소유자가 소유 한 파일을 생성합니다. 일부 프로그램은 특정 사용자가 파일을 소유하고 있는지 확인하여 파일 사용 요청이 적법한 지 확인하며 더 이상 안전하지 않습니다 (프로그램은 액세스 경로의 디렉토리가 해당 사용자가 소유하고 있는지 확인해야합니다). 임의의 마운트가 허용 된 경우, 루트 또는 원하는 사용자가 마운트를 작성하지 않은 마운트 지점이없는 디렉토리도 확인해야합니다.

실제적인 목적으로 오늘날 FUSE를 통해 루트가 아닌 파일 시스템을 마운트 할 수 있습니다 . FUSE 드라이버는 마운팅 사용자로 실행되므로 커널 코드의 버그를 악용하여 권한 상승 위험이 없습니다. FUSE 파일 시스템은 사용자에게 생성 권한이있는 파일 만 노출 할 수 있으므로 위의 마지막 문제가 해결됩니다.

사용자가 블록 장치에 직접 쓰기 권한을 가지고있는 경우 및 해당 블록 디바이스를 탑재 할 수 그들은, 마운트, 블록 장치에 SUID 실행 파일을 작성하고, 그 파일을 실행하고, 따라서, 시스템의 루트 권한을 획득 할 수있다. 이것이 일반적으로 마운팅이 루트로 제한되는 이유입니다.

이제 root는 일반 사용자가 특정 제한 사항으로 마운트 할 수있게하지만 사용자가 블록 장치에 대한 쓰기 액세스 권한이있는 경우 마운트에서 suid를 허용하지 않으며 비슷한 문제가있는 devnode를 허용하지 않아야합니다 (사용자가 만들 수 있음) 쓰기 권한이 없어야하는 중요한 장치에 대한 쓰기 권한을 부여하는 devnode).

항상 슈퍼 개인이 필요하지는 않습니다. 에서man mount

   The non-superuser mounts.
          Normally,  only  the  superuser can mount filesystems.  However,
          when fstab contains the user option on a line, anybody can mount
          the corresponding system.

          Thus, given a line

                 /dev/cdrom  /cd  iso9660  ro,user,noauto,unhide

          any  user  can  mount  the iso9660 filesystem found on his CDROM
          using the command

                 mount /dev/cdrom

          or

                 mount /cd

          For more details, see fstab(5).  Only the user  that  mounted  a
          filesystem  can unmount it again.  If any user should be able to
          unmount, then use users instead of user in the fstab line.   The
          owner option is similar to the user option, with the restriction
          that the user must be the owner of the special file. This may be
          useful e.g. for /dev/fd if a login script makes the console user
          owner of this device.  The group option  is  similar,  with  the
          restriction  that  the  user  must be member of the group of the
          special file.

Kormac과 다른 사람들은 이것이 딜레마가 아니라고 지적했습니다. 이것은 모든 사용자가 파일 시스템을 마운트 할 수있는 불변의 권리 를 갖는 시스템 대 사용자에게 명시 적으로 권한을 부여 한다는 철학에 달려 있습니다.

Gilles는 파일 시스템 마운트와 관련된 일부 보안 문제를 해결합니다. 이와 관련된 잠재적 인 기술적 문제에 대한 사전 논의 및 탄젠트 논의는 피할 수 있지만 (의견 참조) 신뢰할 수없는 사용자는 하드 드라이브를 마운트 할 수있는 불변의 권리가없는 것이 공정하다고 생각합니다.

가상 및 원격 파일 시스템 (또는 가상 파일 시스템, la FUSE를 통한 원격 파일 시스템)과 관련된 문제는 덜 중요하지만 보안 문제를 해결하지는 않습니다 (FUSE가 문제를 해결할 수는 있지만 확실하게 문제를 해결할 것임). 이러한 파일 시스템의 데이터는 파일 전송이나 마운트하지 않고 이미지에서 추출하는 도구를 통해 장치를 마운트 할 필요없이 거의 항상 액세스 할 수 있다는 것을 고려해야합니다. 따라서 무언가를 마운트 할 수없는 시스템은 이미지 파일에 기괴하게 배치되었거나 원격 시스템에서 가져 오려는 데이터에 액세스 할 때 극복 할 수없는 문제는 아닙니다. 그렇지 않은 상황 인 경우 다음과 같이 질문하는 것이 좋습니다.

1. 정확히 내가하려고하는 것은 무엇입니까?

2. 나는 어디에서 그것을하려고합니까?

시스템 관리가 공정한 경우 # 2는 왜 # 1이 불가능한지를 설명합니다. 시스템 관리가 불공평하다면 그것은 정치 입니다. "내 sys 관리자가 공평하지 않다"는 문제에 대한 해결책은 sys 관리자가 모든 사용자를 제한 할 수 없도록 OS를 재 설계하지 않는 것입니다.

이 시스템을 통해 수퍼 유저는 명시 적으로 또는 생략 ( "FUSE 제공하지 않음"등)으로 활동을 제한 할 수 있습니다. 권한은이를 달성하는 한 가지 메커니즘입니다. "이 작업을 수행 할 필요는 없습니다."라고 말하는 것이 좋지 않을 수도 있지만, 사실이라면 ... que sera ...이 작업을 수행 할 필요는 없습니다. ftp 등을 사용하십시오. 사실이 아닌 경우 책임이있는 사람들을 괴롭 히십시오.

참고 : 최신 커널은 "네임 스페이스"를 지원합니다. 일반 사용자는 네임 스페이스를 만들 수 있으며 해당 네임 스페이스 내에서 root 마운트 파일 시스템과 같은 재미있는 요소 가 되고 수행 할 수 있습니다.

"실제"수퍼 유저 권한은 제공하지 않습니다. 이미 허용 된 작업 만 수행 할 수 있습니다 (예 : 이미 읽을 수있는 장치 만 마운트 할 수 있음).

http://lwn.net/Articles/531114/ 섹션 4를 참조하십시오.

마운트하려는 파일 시스템의 데이터가 서버의 보안을 손상 시키거나 의도적으로 구성한 경우 충돌 할 수 있습니다.

그놈에서 gvfs는 원격 파일 시스템 (ftp 또는 ssh)을 마운트하기 위해 루트가 필요하지 않으며 gnome-mount는 외부 저장소 (usb 드라이브, CD / DVD 등)를 마운트하기 위해 루트가 필요하지 않습니다.

대부분의 시스템은 원격 마운트를 위해 그놈 전체를 갖고 싶지 않은 경우 lufs , sshfs 또는 ftpfs를 사용할 수 있습니다 .

gvfs, lufs, sshfs 및 ftpfs는 루트가 아닌 사용자가 가상 ​​파일 시스템을 마운트 할 수 있도록 FUSE를 사용합니다. mount와 달리 -o userFUSE는 sysadmin이 특정 마운트를 정렬하도록 요구하지 않습니다. 마운트 디렉토리 및 파일 시스템을 구성하는 데 필요한 모든 리소스에 대한 권한이 있으면 FUSE 마운트를 만들 수 있습니다.

mount에 루트 권한이 필요한 이유는 무엇입니까?

mount주로 / 원래 로컬 파일 시스템을위한 것이기 때문에 거의 항상 하드웨어가 필요합니다.