facl, setfacl, 디렉토리 공유, cp가 원래 파일 권한을 facl 마스크에 넣는 이유는 무엇입니까? 이것이 cp -p 동작으로 간주되지 않습니까?

이 시스템의 사용자는 주의를 기울여 umask를 매우 개인적인 0077로 설정했습니다. 그러나 사용자는 다른 그룹 구성원 간에 명시적으로 공유할 수 있도록 파일을 복사할 수 있는 그룹별 디렉터리를 갖고 싶어합니다. 이러한 공유 디렉터리는 여러 개 있을 수 있지만 각 디렉터리는 그룹에 따라 다릅니다.

공유를 위해 특정 디렉토리에 그룹 고정 비트를 설정하는 것만으로는 충분하지 않습니다. 고정 비트를 설정하면 디렉터리에 있는 파일의 그룹 소유권이 올바르게 설정되지만 해당 파일에 대한 권한은 일반적으로 파일을 읽거나 편집할 수 없도록, 즉 실제로 공유할 수 없도록 설정됩니다. 디렉토리 목록에만 표시됩니다. 이는 일부 사용자가 읽기 및 쓰기를 허용하기 위해 필요한 그룹 권한 조정을 수동으로 수행하는 방법을 원하지 않거나 모르기 때문입니다. 결국 사용자는 관리자가 아니기 때문에 잠시 휴식을 취할 수 있습니다. 액세스 제어 목록acl이 없는 그룹의 권한과 관계없이 특정 그룹이 공유 디렉터리의 파일에 액세스할 수 있도록 지정하는 데 사용할 수 있습니다. 완벽한 솔루션이지만 잘 작동하지 않습니다.

아래에서 공유 그룹은 "customer_gateway"이고 파일을 공유하려는 예시 사용자는 "svw"입니다. 스크립트에서 볼 수 있듯이 svw 사용자는 customer_gateway 그룹의 구성원입니다. 공유가 이루어지는 디렉토리는 "customer_gateway/"라고도 합니다.

다음은 acl을 사용합니다. 그룹 권한, 기본 그룹 권한, 마스크 및 기본 마스크를 설정합니다. 이는 디렉토리에 생성되거나 cat(또는 tar)을 통해 이동된 파일에 대해 작동하지만 이상하게도 거기에 "cp"가 있는 파일에는 작동하지 않습니다.

# rm -r customer_gateway/
# umask
0077
# cat ~/script1

mkdir customer_gateway
chown :customer_gateway customer_gateway/
chmod g+rwx  customer_gateway/
setfacl -m group:customer_gateway:rwX customer_gateway/
setfacl -m d:group:customer_gateway:rwX customer_gateway/
setfacl -m m::rwX customer_gateway/
setfacl -m d:m::rwX customer_gateway/
getfacl customer_gateway
cd customer_gateway
touch cga
cat << EOF > cgb
c g b
EOF
ls -l

# . ~/script1
# file: customer_gateway
# owner: root
# group: customer_gateway
user::rwx
group::rwx
group:customer_gateway:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:customer_gateway:rwx
default:mask::rwx
default:other::---

total 4
-rw-rw----+ 1 root root 0 Mar  2 20:43 cga
-rw-rw----+ 1 root root 6 Mar  2 20:43 cgb

# su - svw
/home/svw/bin:/usr/local/bin:/usr/bin:/bin

(note umask is 0077)

> cd /share/customer_gateway/
> groups
svw adm dip video plugdev google-sudoers customer_gateway
> cat >> cga
e f g
> cat > cgc
c g c
> ls -l
total 12
-rw-rw----+ 1 root         root         6 Mar  2 20:44 cga
-rw-rw----+ 1 root         root         6 Mar  2 20:43 cgb
-rw-rw----+ 1 svw svw 6 Mar  2 20:44 cgc
> ls ~/dat
ta  tb  tc
> cat ~/dat/ta > ta
> cp ~/dat/tb tb
> ls -l
total 20
-rw-rw----+ 1 root         root         6 Mar  2 20:44 cga
-rw-rw----+ 1 root         root         6 Mar  2 20:43 cgb
-rw-rw----+ 1 svw svw 6 Mar  2 20:44 cgc
-rw-rw----+ 1 svw svw 4 Mar  2 20:45 ta
-rw-------+ 1 svw svw 4 Mar  2 20:45 tb
> getfacl ta
# file: ta
# owner: svw
# group: svw
user::rw-
group::rwx          #effective:rw-
group:customer_gateway:rwx  #effective:rw-
mask::rw-
other::---
> getfacl tb
# file: tb
# owner: svw
# group: svw
user::rw-
group::rwx          #effective:---
group:customer_gateway:rwx  #effective:---
mask::---
other::---
> 

이는 디렉터리에 파일이 생성되면 기본 권한을 받고 공유할 수 있음을 나타냅니다. 그러나 사용자는 항상 거기에 파일을 만드는 것은 아니며 일반적으로 거기에 파일을 복사합니다.

하지만 복사본을 만드는 것도 마찬가지입니다. 왜냐하면 복사본을 만들려면 먼저 새 파일을 만들어야 하기 때문입니다. 여기서는 허가 예약 복사본이 아닌 일반 복사본에 대해 이야기하고 있습니다. 다음과 같은 형식입니다. 그런데 원래 그룹 권한에 관계없이 디렉터리에서 공유될 파일이 작동하고 복사됩니다.

cat < data.in  > shared/data.out

훌륭하게 작동하고 타르 파이프를 통해서도 작동하지만

cp data.in shared/data.out

실패하다. ed cat파일은 기본 마스크와 기본 권한을 갖습니다. ed cp파일은 마치 cp -p인 것처럼 acl 마스크 및 그룹 권한 내에서 권한을 유지하므로(그렇지 않음) 유효 권한은 acl이 설정한 것이 아니라 원본 파일처럼 읽혀집니다.

두 번째 시도로, 그룹 고정 비트 chmod g+rwxs와 facl 변경을 사용하여 이 실험을 실행했고 정확히 동일한 결과를 얻었습니다. 그러나 모든 공유 파일에는 그룹 소유권이 표시되므로 디렉터리 목록이 더 아름답습니다. 또한 setfacl을 사용하여 실행하지 않고 그룹 고정성 비트를 설정했습니다. 복사된 파일에 대해서도 동일한 결과가 적용됩니다(따라서 facls는 공유를 위해 파일이 복사되는 디렉토리에 대해서는 다소 쓸모없어 보입니다).

Linux facls가 생성된 데이터의 다양한 형태를 구별하는 기초와 이유는 무엇입니까? cp가 권한을 유지하라는 지시 없이 강제로 권한을 유지하도록 하는 이유는 무엇입니까? 작동하지만 cp는 작동하지 않는 tar를 통해 cat과 파이핑의 차이로 인한 혼란을 정당화할 이유가 있습니까? 이 구별을 사라지게 만드는 마법 주문을 놓치고 있는 걸까요?

이 요약이 맞습니까? facls를 사용하면 공유 파일의 소유권을 극복할 수 있습니다. 파일을 "생성"할 때 생성이 cp 명령으로 인한 것이고 타당한 이유가 있는 경우를 제외하고는 umask보다 권한이 더 허용됩니다. .왜?