-
rootfs 커스터마이징(1)Yocto 2024. 6. 14. 01:17
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...
'Yocto' 카테고리의 다른 글
#FT4232HL #RS485 #rootfs (0) 2024.06.24 #rootfs #clamav #swap (0) 2024.06.24 rootfs 커스터마이징(2) (2) 2024.06.15