일반 사용자로서 파일 소유권을 변경할 수 있는 이유는 무엇입니까?

일반 사용자로서 파일 소유권을 변경할 수 있는 이유는 무엇입니까?

Netapp SAN에서 NFS를 통해 파티션을 마운트했습니다. 해당 파티션에 파일을 생성하고 해당 파일을 다른 사용자, 모든 사용자, 심지어 루트에게 권한을 부여할 수 있습니다. 어떻게 해야 하나요? 나는 커널이 이런 일이 일어나는 것을 막을 것이라고 생각했습니다. 저는 오늘도 파일에 여러 사용자 ID를 사용하여 이 작업을 반복하고 있습니다.

/tmp 또는 로컬 설치의 홈 디렉토리에서는 이 작업을 수행할 수 없습니다.

나는 이전에 이런 행동을 본 적이 없습니다. 또한 이 컴퓨터에서는 setcap/getcap을 찾을 수 없다는 것을 알았습니다.

쉘의 기능을 확인했는데 모두 0입니다.

$ echo $$
15007
$ cat /proc/15007/task/15007/status 
Name:   bash
State:  S (sleeping)
SleepAVG:       98%
Tgid:   15007
Pid:    15007
PPid:   14988
TracerPid:      0
Uid:    71579   71579   71579   71579
Gid:    10000   10000   10000   10000
FDSize: 256
Groups: 9000 10000 10001 10013 10018 10420 24611 36021 
...
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000

저는 Red Hat 5.3 가상 머신을 사용하고 있습니다.

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)

이전 커널 실행:

$ uname -r
2.6.18-274.7.1.el5

NFS 마운트는 기본값을 사용합니다.

$ cat /etc/fstab
...
mynetapp00:/home /mnt/home nfs defaults 0 0

사용자 인증을 위해 우리는 Linux 측에서 Windows Active Directory와 ldap을 사용합니다.

$ grep passwd /etc/nsswitch.conf 
passwd:     files ldap

sudo로 무엇이든 할 수 있습니다.

User mikes may run the following commands on this host:
    (ALL) ALL

나는 관리자 중 한 명이기 때문에(/etc/sudoers의 내용):

User_Alias      ADMINS = fred, tom, mikes
ADMINS          ALL=(ALL) ALL

...하지만 sudo가 관련되지 않았기 때문에 무슨 일이 일어나고 있는지 모르겠습니다. 어쨌든 파일을 생성하고 /etc/sudoers에는 없는 "john" 사용자로 소유권을 부여할 수 있었습니다.

# grep john /etc/sudoers
# su - john
$ touch /mnt/home/blah
$ chown mikes /mnt/home/blah   
$ ls -l /mnt/home/blah
-rwxrwxrwx 1 mikes DomainUsers 0 Oct 23 19:45 /mnt/home/blah

...그리고 chown에는 별칭이 없습니다(그러나 chown이 별칭이거나 다른 프로그램인 경우 /tmp에서 소유권을 변경할 수도 있기 때문에 우리는 알고 있습니다).

$ alias
alias l.='ls -d .* --color=tty'
alias ll='ls -l --color=tty'
alias ls='ls --color=tty'
alias vi='vim'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
$ which chown
/bin/chown

추신: 농담이 아닙니다.

$ id
uid=71579(mikes) gid=10000(DomainUsers)
$ touch /mnt/home/blah
$ chown john /mnt/home/blah
$ ls -l /mnt/home/blah
-rwxrwxrwx 1 john DomainUsers 0 Oct 23 19:04 /mnt/home/blah
$ id john
uid=37554(john) gid=10000(DomainUsers)
$ chmod 755 /mnt/home/blah
chmod: changing permissions of `/mnt/home/blah': Operation not permitted
$ rm /mnt/home/blah
$ ls -l /mnt/home/blah
ls: /mnt/home/blah: No such file or directory
$ touch /tmp/blah
$ chown john /tmp/blah
chown: changing ownership of `/tmp/blah': Operation not permitted

답변1

예, chown이것은 커널의 범위입니다. 그러나 NetApp은 커널의 범위를 벗어납니다. 로컬 파일 시스템의 경우 커널은 사용자 I/O 요청을 로컬 하드웨어 I/O 작업(저장 장치에서)으로 변환합니다. 원격(예: NFS) 파일 시스템의 경우 커널은 사용자 I/O 요청을 네트워크 통신으로 변환하여 사용자가 원하는 작업을 수행하도록 서버에 요청/지시합니다.

서버가 요청을 준수한다는 보장은 없습니다. 예를 들어 Unix 스타일 권한과 Windows 스타일 권한을 모두 지원하도록 NetApp 서버를 구성할 수 있습니다. Unix/Linux 클라이언트에는 Unix 스타일 권한(사용자, 그룹, 모드 및 ACL)이 표시됩니다. Windows 클라이언트는 Windows 스타일 권한(그룹, 속성, ACL 및 확장된 속성을 제외한 사용자)을 볼 수 있습니다. NetApp은 파일 속성의 조합을 내부적으로 저장하고 일부 모호한 독점 알고리즘을 기반으로 액세스를 적용하므로 Unix 클라이언트에 표시되지 않는 Windows 스타일 권한 제한으로 인해 Unix 작업이 거부될 수 있습니다.

긴 이야기 짧게
NetApp 서버는 권한을 적용합니다. 따라서 NetApp의 NFS 드라이버는 권한 확인을 수행하도록 작성되지 않고 대신모두사용자가 서버에 요청을 합니다. 따라서 실행 허용 여부는 chownNetApp이 100% 결정할 수 있습니다.

왜 이런 일이 발생하는지 모르겠습니다. 이는 버그일 수 있습니다. NetApp이 출시된 지 25년이 되었기 때문에 지금쯤이면 이렇게 큰 버그가 보고되고 수정될 것으로 예상했기 때문에 이는 다소 놀라운 일입니다. NetApp의 구성 설정일 수 있습니다. 이는 실제로 말이 되지 않지만 서버 관리자가 자신이 수행하는 작업을 잘 이해하지 못할 수도 있습니다(또는 이러한 방식으로 구성된 모호한 정책 이유가 있을 수도 있습니다).

답변2

또 다른 추측은 NFS 익명 액세스가 uid 0(즉 루트)에 직접 매핑되므로 원하는 경우 이를 차단할 수 있다는 것입니다. 이는 anonuid nfs 서버 구성 매개변수와 netapp의 내보내기 정책 구성을 사용하여 수행할 수 있습니다.

또한 참고: 붙여넣은 셸 출력은 소유자가 변경되었음을 증명하지 않습니다. "chown"을 실행하기 전에 "ls -l"을 실행하지 않았으므로 또 다른 가능성은 익명으로 NFS 내보내기에 액세스했으며 서버가 다음과 같이 구성되었을 수 있습니다. 익명 액세스 사용자 이름 "john"이 매핑되었으므로 chown 명령에 대해 아무것도 변경할 필요가 없습니다.

참고자료:

https://serverfault.com/questions/539267/nfs-share-with-root-for-anonuid-anongid

https://kb.netapp.com/app/answers/answer_view/a_id/1029865/~/how-to-create-a-root-squash-export-policy-rule-on-clustered-data-ontap-

https://linux.die.net/man/5/exports

답변3

이것은 약간의 빛을 비출 수 있습니다. 나는 사용한다 sshfs. .ssh

내가 이것을 할 때마다. 모든 파일 작업은 파일 시스템을 마운트하는 데 사용하는 원격 시스템의 사용자가 제어합니다. 그렇다면 다음과 같이 하세요.

sshsf «remote-user-name»@«remote-machine-name»:~ «local-mount-point»

그러면 모든 것이 원격 사용자로서 수행됩니다. 다른 점이 없다 sudo.

원격 사용자에게 상승된 권한이 있는 경우 마운트 액세스 권한을 얻은 모든 로컬 사용자는 상승된 권한을 갖게 됩니다.

관련 정보