CentOS/Red Hat 6에서 ACL을 배우고 있습니다. getfacl
절대 경로로 실행하면 다음과 같은 결과가 나타납니다.
getfacl: 절대 경로 이름에서 선행 "/" 제거
이것이 왜 필요한가요? 언제 -p
또는 스위치를 사용해야 합니까 --absolute-names
?
Wale Soyinka와 Michael Zhang이 쓴 내 책에서는 이에 대해 언급조차 하지 않고 매뉴얼 페이지에서도 단서를 찾을 수 없으며 이 경고를 직접적으로 다루는 사이트도 찾을 수 없는 것 같습니다.
답변1
매뉴얼 페이지에서 getfacl
:
-p, --absolute-names
Do not strip leading slash characters (`/'). The default behavior
is to strip leading slash characters.
스위치를 사용하지 않고 절대 경로를 제공하면 경고 메시지가 표시됩니다 -p
.
명령에 절대 경로를 제공하면 출력이 달라집니다 getfacl
.
스위치 없이 -p
:
$ getfacl /path/foo/bar
getfacl: Removing leading '/' from absolute path names
# file: path/foo/bar
[Output truncated...]
파일 경로의 선행 슬래시는 -p
스위치를 사용할 때만 나타납니다.
$ getfacl -p /path/foo/bar
# file: /path/foo/bar
[Output truncated...]
-p
추가 처리를 위해 출력을 파이핑할 때 선행 슬래시를 유지하는 것이 유용합니다.
명령에 상대 경로를 제공하면 출력은 동일합니다 getfacl
.
$ getfacl bar
# file: bar
[Output truncated...]
변경 없음:
$ getfacl -p bar
# file: bar
[Output truncated...]
답변2
난 그렇게 생각하지 않아"'-p' 플래그를 사용하지 않았기 때문에"정말 설명했어.목적이 경고의.
이러한 명령은 전통적인 POSIX 권한이 허용하는 더 강력한 보안을 분명히 고려하여 세분화된 보안 조치를 구현하도록 설계되었습니다.
그래서 나는 안전 이론으로 돌아가서 각 경우에 무엇이 잘못될 수 있는지 생각하고 "가장 안전한" 기본값을 선택합니다.
- 예상대로 상대 또는 절대 경로를 사용하십시오. 문제 없습니다.
- 절대 경로를 사용해야 하는 경우 상대 경로 사용: 작동하지 않지만 보안 취약점을 일으킬 가능성은 낮습니다. (또한 사전에 쉽게 고칠 수 있습니다
cd /
.) - 상대 경로를 사용해야 하는 경우 절대 경로를 사용하십시오. 이것이 바로 이 제한이 강조하려는 의도입니다.
프로젝트 설치 스크립트 고려
setfacl -m u:1234:rw $project_dir/etc/passwd
$project_dir
이제 오류가 발생했는데 비어 있으면 어떻게 될지 생각해 보세요 . (그렇게 철자를 써야 할 수도 $projectdir
있고, 구성 파일이 누락되어 설정되지 않았거나, 다른 종류의 버그가 있을 수도 있습니다.)
getfacl
사용 사례 중 하나가 다음과 같이 동일한 원칙이 적용됩니다 .
getfacl some/file | { make some changes } | setfacl -b -M- some/file
또는 동등하게
getfacl some/file > aclfile
edit aclfile
setfacl -b -M aclfile some/file
아마도 더 중요한 것은
getfacl some/file > aclfile
edit aclfile
setfacl --restore=aclfile
(마지막 경우 대상 파일 이름은 다음과 같습니다.아니요명령줄 에 포함되어 있으며 setfacl
aclfile에서 읽혀집니다. )
"이것은 , , 및 와 동일한 방식으로 작동해야 한다"고 생각할 수 있으며 chmod
어떤 의미에서는 맞습니다. 이러한 명령은 통보되지 않은 절대 경로에 대해 동일한 제한이 있으면 더 안전할 것입니다.chown
chgrp
install
그러나 이러한 명령은 오랜 역사적 선례(주로 그 뒤에 있는 POSIX 표준)를 가지고 있으므로 보안 전문가가 좋은 생각이라고 생각하더라도 협상에 실제로 적합하지 않습니다.
이는 다른 곳에서도 전례가 없는 것은 아닙니다.
rsync -R
경로를 수신 측에서 상대 경로로 취급하고 선행 경로는 무시합니다 /
.
및 ( 이전에는 패키지 전달에 사용되었으며 대중화 됨 ) cpio
와 같은 아카이버에는 같은 이유로 행간을 잘라내는 옵션이 있지만 기본 설정은 반대입니다(해제).tar
deb
rpm
/