rootfs 커스터마이징(1)

Yocto 빌드로 생성된 rootfs 를 커스터마이징하는 나의 일련의 시행착오들을 나열한다.

 

먼저 빌드 환경에 대해 정리하자면 다음과 같다.

- Ubuntu: 20.04.06 LTS

- Yocto: krikstone-5.15.71_2.2.0

- Machine: IMX8M-MINI

- Recipe: imx-image-multimedia

 

weston 계정 디렉터리 및 파일 소유권에 따른 systemd 초기화 실패

weston 계정(GUI 지원 계정)이 /var 디렉터리에 대한 소유권을 가짐에 따라 여러 systemd를 수행하는  root 계정은 /var 디렉터리 하위에 생성해야 하는 여러 디렉터리 및 파일들을 생성할 수가 없음.

 

이에 따라 systmed 초기화 과정에 실패가 발생함.

 

이러한 과정을 확인하게 된 이유는 clamav라는 백신 프로그램을 meta-security layer를 추가함으로써 Yocto rebuild 후 포팅 되었으나 clamav 검사 DB를 가져오기 위한 freshclam을 수행하는 과정에서 /var/log/clamav, /var/lib/clamav 등에 대한 접근 permission 에러가 발생했기 때문이다.

 

chown, chmod 명령어를 통해 소유권 및 접근 권한을 수정하여 수행되게 하였지만 이를 해결하기 위한 원초적인 부분을 찾는 것이 필요하다고 생각했다.

 

그래서 무엇을 해보았느냐?

 

먼저 systemd-tmpfiles 라는 것을 통해 tmpfs가 마운트 된 /var/volatile 디렉터리 하위에 여러 임시 디렉터리 및 파일들이 생성되게 되는데 앞서 말했듯 /var 디렉터리 소유권이 weston 이기 때문에 systemd를 수행하는 root 입장에서는 자신의 소유권이 아니었기 때문에 정상적으로 수행되지 못했다. 

 

물론 생성되는 파일이나 디렉터리도 있지만 확실한 건 /var/log 및 /var/tmp 가 링크 파일로서 /var/volatile/log 및 /var/volatile/tmp 에 연결되어야 정상적인 수행으로 간주되는데 /var/volatile 밑에 log 및 tmp 디렉터리를 생성하지 못했기 때문에 소유권에 대한 영향은 분명함을 확인했다.

(이들이 생성할 디렉터리 및 파일은 /etc/tmpfiles.d/ 또는 /usr/lib/tmpfiles.d/ 하위에 *.conf 파일로 존재한다.)

 

그리하여 /var 에 대한 소유권을 root로 명시 후 reboot를 하자 systemd-tmpfiles 가 정상적으로 동작하는 것이 아닌가!

 

확신이 선 나는 freshclam을 다시 수행해보았다.

 

/var/log/clamav 에 대한 소유권 문제는 해결되었다!

 

그러면 이제 /var/lib/clamav에 대한 접근 문제인데 이 디렉터리 역시 weston이 소유하고 있다. 

 

weston이 소유한다는 건 weston의 .bashrc를 보면 umask 022를 명시하고 있는데 이에 대한 영향인지는 확실하지 않지만 rwx 중 w 권한이 빠진 것으로 clamav 계정 입장에서는 w가 불가능하므로 접근 에러가 발생한 것으로 판단된다.

 

따라서 마찬가지로 소유권을 명시하든 접근 권한을 수정하든 하면 해결될 것으로 판단했다.

 

그러면 더 원초적인 문제로 접근해보자면

 

대체 왜

 

weston 계정이 / 디렉터리 하위 일부 디렉터리 및 파일들에 대해서 소유권을 가지고 있게 된 것일까?

 

오늘의 일기는 다음의 여지로 마무리 짓는다.

 

구글 검색으로 yocto rootfs weston user 를 검색해보니 weston이 root 로서 동작하지 않게 하는 방법에 대한 질문들이 종종 보였다.

 

weston에는 어떻게 root 권한이 부여되었고 그렇다면 root는 어떻게 root 권한을 갖게 되는 걸까?

 

To be continue...