/root소유자가 쓸 수 없는 것으로 표시한 이유 에 대한 문서가 있습니까 ? ( r-xr-x---)
CAP_DAC_OVERRIDE를 사용하면 소유자가 일반적으로 쓰기 액세스 권한을 갖는다는 것을 알고 있습니다. 그런데 이걸 보고 또 놀랐다. 그래서 이것으로부터 무엇인가 배울 수 있는지 궁금합니다!
나에게는 데비안의 접근 방식이 더 자연스러워 보입니다. 데비안에서는 권한이 rwx------.
$ rpm -q --whatprovides /root
filesystem-3.2-37.fc24.x86_64
$ sudo dnf info filesystem | grep Release
Release : 37.fc24
$ grep ^VERSION= /etc/os-release
VERSION="25 (Workstation Edition)"
답변1
2009년경 Fedora는 이를 변경했습니다. 원천:https://bugzilla.redhat.com/show_bug.cgi?id=517575P
이 점을 지적해주신 @jordanm에게 감사드립니다. 관련 인용문을 복사해 보았습니다. 면책조항: 이 렌더링에서 뭔가 손실된 것이 확실합니다.
이러한 변경으로 인해 루트에서 쓰기 권한이 제거되므로 쓰기 위해서는 DAC_OVERRIDE도 필요합니다. 그런 다음 루트가 필요하지만 네트워크 또는 setuid 지향적인 기능을 삭제했습니다.
비판적인 반응
어쨌든 선의의 아이디어이지만 실제로는 uid 0이지만 CAP_DAC_OVERRIDE가 아닌 프로세스는 여전히 u+w가 있는 /usr/bin/bash를 완벽하게 다시 작성할 수 있기 때문에 추가 작업 없이는 작동하지 않습니다. 또는 /root/.bashrc. 이러한 유형의 문제에 대한 답은 SELinux입니다. Recovery Catalog Mode 755 패치에 대해 이의가 있으신가요?
저자의 답변:
[귀하의 소프트웨어]에 어떤 문제가 있습니까? 시스템 디렉터리에 쓰려고 하면 문제가 있는 것입니다.
회신하다:
이것은 큰 문제가 아닙니다. rpm-ostree를 효과적으로 복원하는 코드는 크기가 작고 시간이 지나도 휴대하기 어렵지 않습니다.
나는 이 문제를 겪는 다른 사람들이 우리가 rpm-ostree에서 변경한 내용을 볼 수 있도록 이러한 오류를 상호 연결하고 싶었습니다.
제3자 애도: 이 문제를 해결하기 위해 학급의 모든 도구에 필요한 패치워크에 관한 것입니다.
https://github.com/projectatomic/rpm-ostree/pull/335
이 문제를 야기한 Fedora 버그에 연결하고 "작성" 사례에서도 작동하도록 변경하십시오. 이유는 다음과 같습니다.
- 다시 말하지만 보안을 추가하지 않습니다.
- "작성" 저장소에서 실행되는 도구는 체크아웃 시 이 문제를 해결해야 합니다.https://lists.freedesktop.org/archives/xdg-app/2016-June/000241.html