명령줄에서 쓰기 불편한 Flatpak

AI 요약

Flatpak은 여러 Linux 배포판에서 같은 앱을 배포하고, 샌드박스로 접근 권한을 제한하는 패키지 형식입니다. 그래픽 앱은 소프트웨어 스토어에서 설치하고 실행하는 흐름이 자리 잡았지만, 명령줄 도구는 사용하기 불편합니다. 배포판 패키지로 설치한 flatpak-builder는 flatpak-builder build-folder manifest.yaml로 실행하지만, Flatpak 앱으로 설치하면 전체 앱 ID를 포함한 flatpak run org.flatpak.Builder build-folder manifest.yaml을 입력해야 합니다. 샌드박스 파일 시스템 접근도 별도로 풀어야 합니다.

`--file-forwarding`의 제약

Flatpak의 --file-forwarding 옵션은 @@ 사이에 지정한 파일을 샌드박스 안으로 전달합니다. 하지만 명령이 짧아지지는 않습니다. 이 방식은 기존 파일을 전달하는 데 초점을 두므로 디렉터리나 아직 존재하지 않는 출력 파일을 다루기 어렵습니다. 예를 들어 이미지 변환 도구에서 새 출력 경로를 지정하는 경우에는 그대로 적용되지 않습니다.

Windows 실행 별칭을 본 제안

글은 Windows 10의 App Execution Alias를 참고합니다. UWP와 Desktop Bridge 앱은 매니페스트에 uap3:AppExecutionAlias를 선언해 샌드박스 밖에서 실행할 이름을 내보냅니다. Windows는 %LOCALAPPDATA%\Microsoft\WindowsApps에 별칭 파일을 만들고, 이 디렉터리가 사용자의 PATH에 들어가므로 명령줄에서 별칭을 실행할 수 있습니다. 별칭이 다른 프로그램과 충돌하면 시스템 설정에서 끌 수 있습니다. 글은 python을 입력했을 때 직접 설치한 Python 대신 Microsoft Store가 열리는 사례를 충돌 예로 듭니다.

Flatpak에 적용할 방안으로 매니페스트에 export-commands 항목을 두고, 패키지 내부 실행 파일을 짧은 명령 이름에 연결하자고 제안합니다. 예시에서는 PuTTY 앱이 putty, puttygen, psftp, pageant, pscp를 별칭으로 내보냅니다. flatpak-builder는 이 설정을 앱 메타데이터의 [Commands] 섹션으로 기록합니다.

설치 과정에서는 별칭마다 래퍼 스크립트를 생성합니다. 래퍼는 --command 옵션으로 내부 실행 파일을 지정하고, --file-forwarding을 붙여 Flatpak을 실행합니다. 글에 실린 스크립트는 인수마다 경로가 실제 파일인지 확인하고, 존재하면 절대 경로를 @@로 감싸 전달합니다. 별칭 허용 여부를 관리하는 Flatpak 하위 명령을 추가하고, 시스템 설정이나 Flatseal 같은 그래픽 도구에서 별칭을 켜고 끄는 인터페이스를 제공하자는 제안도 덧붙입니다.

제안된 파일 전달 방식의 한계

Lobsters 댓글은 --file-forwarding이 주로 자동 생성된 .desktop 파일에서 쓰인다고 설명합니다. 데스크톱 환경은 파일을 열 때 전달할 기존 파일과 URL을 %U로 넘깁니다. 따라서 옵션이 기존 파일을 전제로 하고 디렉터리를 대상으로 삼지 않는 이유도 여기에 있습니다. Flatpak은 이미 /var/lib/flatpak/exports/bin이나 사용자 디렉터리에 명령 별칭을 내보내지만, 현재는 전체 역방향 도메인 이름을 사용합니다. 더 나은 별칭 지원을 논의하는 이슈가 열려 있으나, 해결할 질문이 남아 있고 한동안 작업도 진행되지 않았다고 댓글은 전합니다.

댓글은 글의 래퍼 스크립트가 모든 명령줄 인수를 올바르게 처리하지 못한다고 지적합니다. grep -fpatterns.txt처럼 파일 이름이 옵션에 붙어 있으면 스크립트가 이를 별도 경로 인수로 알아볼 수 없습니다. 앱마다 명령줄 문법이 다르므로 래퍼가 외부에서 파일 인수를 정확히 판별하기 어렵다는 설명입니다. 보안 문제도 제기합니다. 앱이 접근 가능한 디렉터리에 /를 가리키는 subcommand 심볼릭 링크를 만들고, 사용자가 나중에 thething subcommand를 실행하면 앱에 홈 디렉터리 전체 접근 권한이 생길 수 있다는 사례입니다. 댓글 작성자는 Flatpak이 GUI를 중심으로 샌드박싱을 설계한 선택도 CLI 지원이 덜 다듬어진 배경으로 봅니다.

원문: kowalski7cc.xyz / 번역·요약: Trawling

Lobsters 반응

• @refi64 — --file-forwarding은 주로 자동 생성된 .desktop 파일에서 씁니다. 예를 들면 ~/.local/share/flatpak/exports/share/applications/md.obsidian.Obsidian.desktop에는 /usr/bin/flatpak run --branch=stable --arch=aarch64 --command=obsidian.sh --file-forwarding md.obsidian.Obsidian @@u %U @@ 같은 실행 줄이 들어갑니다. %U는 파일을 열 때 프로그램에 전달하는 파일과 URL로 확장됩니다. 그래서 --file-forwarding은 기존 파일을 전제로 하고 디렉터리를 대상으로 삼지 않습니다. 명령 별칭은 이미 /var/lib/flatpak/exports/bin이나 ~/.local/share/flatpak/exports/bin에 내보내지만, 전체 역방향 도메인 이름을 사용합니다. 더 나은 별칭 지원을 추가하자는 열린 이슈가 있지만 해결해야 할 질문이 있고, 한동안 아무도 작업하지 않았습니다. 특히 자동 --file-forwarding 지원은 포함되지 않았습니다. 제대로 구현하기가 불가능하기 때문입니다. 글의 스크립트는 옵션과 값이 붙어 있는 인수에서는 작동하지 않습니다. grep -fpatterns.txt처럼 파일 이름이 더 큰 옵션 일부라면 스크립트가 이를 처리할 수 없습니다. 앱이 실제로 어떤 CLI 문법을 쓰는지 바깥에서 정확히 알 수 없습니다. 보안 문제도 있습니다. 앱이 접근할 수 있는 폴더에 /를 가리키는 subcommand 심볼릭 링크를 만든 뒤, 나중에 사용자가 thething subcommand를 실행하면 바이너리가 사용자의 홈 디렉터리 전체에 접근할 수 있습니다. 글은 CLI 앱이 뒤처졌다고 말하지만, 제가 이해하기로는 Flatpak이 의도적으로 내린 설계 결정에 가깝습니다. 샌드박싱 방식을 한 가지 UX, 즉 GUI에 맞춰 설계하는 편이 여러 방식을 지원하다가 전부 제대로 못 하는 것보다 쉽습니다. 그래서 CLI 지원은 덜 다듬어졌습니다. 애초에 그 방식으로 사용하도록 설계하지 않았기 때문입니다.