Linux에서 사용자가 무언가를 마운트하기 전에 각 마운트에 대해 루트/sudo 사용/특별한 승인을 받아야 하는 이유는 무엇입니까? 사용자가 무언가를 설치하도록 허용할지 여부는 소스 볼륨/네트워크 공유 및 마운트 지점에 대한 액세스를 기반으로 결정해야 하는 것 같습니다. 루트가 아닌 사용자 설치의 몇 가지 용도는 파일 시스템 이미지를 사용자 소유 방향으로 마운트하고 네트워크 공유를 사용자 소유 디렉터리에 마운트하는 것입니다. 사용자가 설치 방정식의 양면을 제어할 수 있다면 멋질 것 같습니다.
액세스 제한 설명:
사용자가 속한 마운트 지점에 사용자가 액세스할 수 있는 모든 것을 설치할 수 있어야 한다고 생각합니다.
예를 들어, 내 컴퓨터에서 /dev/sda1은 사용자 루트와 권한이 있는 그룹 디스크가 소유합니다 brw-rw----. 그러므로 루트가 아닌 사용자는 /dev/sda1을 망칠 수 없으며 분명히 mount는 그들이 이를 마운트하도록 허용해서는 안 됩니다. 그러나 사용자가 /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가 문제가 되고 잠재적으로 다른 문제가 발생하는 것을 방지하려면 몇 가지 제한 사항을 추가해야 합니다. 아마도 한 가지 방법은 운영 체제가 모든 파일을 설치를 수행하는 사용자에게 속한 것으로 처리하도록 하는 것입니다. 그러나 단순한 읽기/쓰기/실행의 경우 이것이 왜 문제가 될지 모르겠습니다.
사용 사례:
저는 Labs에 계정이 있고 집 공간 제한은 8GB입니다. 이것은 작고 매우 성가신 일입니다. 내 개인 서버에서 nfs 볼륨을 마운트하여 기본적으로 내가 가진 공간을 늘리고 싶습니다. 하지만 리눅스는 이런 것을 허용하지 않기 때문에 8GB 제한을 초과하지 않도록 파일을 앞뒤로 scp'ing해야 했습니다.
답변1
이는 역사적 제한이자 보안 제한입니다.
역사적으로 대부분의 드라이브는 분리할 수 없었습니다. 따라서 합법적인 물리적 액세스 권한이 있고 루트 계정에 액세스할 수 있는 사용자로 설치를 제한하는 것이 합리적입니다. fstab 항목을 사용하면 관리자는 이동식 드라이브 마운트를 다른 사용자에게 위임할 수 있습니다.
보안 관점에서 볼 때 모든 사용자가 블록 장치나 파일 시스템 이미지를 어느 위치에나 마운트하도록 허용하는 데에는 세 가지 주요 문제가 있습니다.
- 소유되지 않은 위치에 설치하면 해당 위치의 파일이 숨겨집니다. 예를 들어, 알고 있는 루트 비밀번호가 포함된
/etc에 원하는 파일 시스템을 마운트합니다 ./etc/shadow이 문제는 사용자가 자신이 소유한 디렉토리에만 파일 시스템을 마운트하도록 허용함으로써 해결될 수 있습니다. - 파일 시스템 드라이버는 잘못된 형식의 파일 시스템에 대해 철저하게 테스트되지 않는 경우가 많습니다. 결함이 있는 파일 시스템 드라이버로 인해 잘못된 형식의 파일 시스템을 제공하는 사용자가 커널에 코드를 삽입할 수 있습니다.
- 파일 시스템을 마운트하면 마운터가 생성 권한이 없는 파일을 표시할 수 있습니다. Setuid 실행 파일과 장치 파일이 가장 확실한 예이며 에 암시적 으로 포함된
nosuid및nodev옵션 으로 수정 되었습니다 . 지금까지는 . 그러나 더 일반적으로는 다른 사용자가 소유한 파일을 생성할 수 있다는 것은 문제가 됩니다. 파일의 내용이 설치 프로그램이 아닌 해당 소유자의 것으로 간주될 가능성이 있습니다. 루트에서 다른 파일 시스템으로 속성을 보존하는 임시 복사본을 복사하면 선언되었지만 관련 소유자는 아닌 소유자가 파일을 소유하게 됩니다. 일부 프로그램은 파일이 특정 사용자에게 속하는지 확인하여 파일 사용 요청이 적법한지 확인하지만 이는 더 이상 안전하지 않습니다(프로그램은 액세스 경로의 디렉터리가 해당 사용자에게 속하는지도 확인해야 합니다. 허용되는 경우 이 디렉터리가 마운트 지점이 아닌지(루트나 필수 사용자가 마운트를 생성하지 않은 경우)도 확인해야 합니다.user/etc/fstabusermount
실용적인 목적으로 이제 다음을 통해 루트 없이 파일 시스템을 마운트할 수 있습니다.퓨즈. FUSE 드라이버는 설치 사용자로 실행되므로 커널 코드의 버그를 악용하여 권한이 상승할 위험이 없습니다. FUSE 파일 시스템은 사용자가 생성 권한을 가진 파일만 노출할 수 있으므로 위의 마지막 문제가 해결됩니다.
답변2
사용자가 블록 장치에 직접 쓰기 액세스 권한을 갖고 있는 경우그리고블록 장치를 마운트한 후 블록 장치에 suid 실행 파일을 작성하고 마운트한 후 파일을 실행함으로써 시스템에 대한 루트 액세스 권한을 얻을 수 있습니다. 이것이 설치가 일반적으로 루트로 제한되는 이유입니다.
이제 루트는 일반 사용자가 특정 제한 사항에 따라 마운트하도록 허용할 수 있지만, 사용자가 블록 장치에 대한 쓰기 액세스 권한을 가지고 있는 경우 유사한 문제가 있는 suid 및 devnode에 대해 마운트가 허용되지 않는지 확인해야 합니다(사용자는 다음을 수행할 수 있음). 수동으로 devnode를 만들고, 쓰기 액세스 권한이 없어야 하는 중요한 장치에 대한 쓰기 액세스 권한을 부여하세요.
답변3
항상 슈퍼 권한이 필요한 것은 아닙니다. ~에서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.
답변4
참고: 최신 커널에는 "네임스페이스" 지원이 있습니다. 일반 사용자는 네임스페이스를 생성하고 root 네임스페이스 내에서 파일 시스템 마운트와 같은 흥미로운 작업을 수행할 수 있습니다.
하지만 "실제" 수퍼유저 권한을 부여하지는 않습니다. 이미 허용된 작업만 수행할 수 있습니다(즉, 이미 읽을 수 있는 장치만 설치할 수 있습니다).
바라보다네임스페이스 작동, 1부: 네임스페이스 개요, 섹션 4.