You don't need to read this post. It is based on outdated information.
As of Sep 2021, the make image
process preserves the permissions of files included in the FILES=
directory. Namely, the "644" portion of the problem no longer exists.*
*To be more accurate, the problem does not exist with the image builder downloaded from this page:
https://downloads.openwrt.org/releases/19.07.8/targets/ath79/generic/
If you have a router for which development has stopped some time ago, you may be living in the past insofar as your router's image builder is concerned.
For the "root owned" portion of the problem, you may want to see this other post,
but only if you are a novice (like me) and don't know what a script must look like that is included in the /etc/uci-defaults
directory.
What follows this line is based on outdated information.
According to these two sources
the image building process assigns to every included file root ownership plus 644 permissions.
If so, I will have a problem when I start wanting to include (in the image) directories and files that should not receive the "root ownership plus 644" treatment.
Examples would include sensitive files that should have more restrictive permissions (see linked sources for examples) and non-root user files that should not be root-owned (e.g. the non-root user home directory).
Question: How can I exclude designated directories and files from the "root owned plus 644" treatment?
Note that the linked sources refer to "modifying include/image.mk" as a solution. My problem with that would be that I don't even know what "include/image.mk" is. I would have to be told something like, "That's part of the XYZ process, which you need to understand. Start here," and the documentation.
Just a week or so ago, I did not know what "image building" was. I am not averse to learning any amount of materials so long as the sources are there and somebody can point them out to me. Thanks.
ADDENDUM
The idea that image building assigns to every included file the "644" permissions may be wrong.
I included these files in the make image
process.
-rw-r--r-- 1 root root 1484 Aug 1 16:46 ssh_config
-rw------- 1 root root 505 Sep 2 03:02 ssh_host_ecdsa_key
-rw-r--r-- 1 root root 174 Sep 2 03:02 ssh_host_ecdsa_key.pub
-rw------- 1 root root 399 Sep 2 02:29 ssh_host_ed25519_key
-rw-r--r-- 1 root root 94 Sep 2 02:29 ssh_host_ed25519_key.pub
-rw------- 1 root root 2602 Sep 2 02:29 ssh_host_rsa_key
-rw-r--r-- 1 root root 566 Sep 2 02:29 ssh_host_rsa_key.pub
-rw-r--r-- 1 root root 3115 Aug 1 16:46 sshd_config
At the time of inclusion in the image building, they had to be non-root owned (per requirement of the process), but with the permissions you see above.
On flashing, their counters in the router had the various 644 and 600 permissions (as above). Namely, permissions were preserved as we have already been told here:
Can I run `image make` even if some files are root-owned? - #8 by vgaetera
Maybe the behavior of make image
has changed since the time of the two links at the top of this post.
I'll do further tests. If permission are preserved, only the "root owned" portion of the problem would remain.
ADDENUM 2
I ran more tests. Put files of various permissions into make image
, flashed the router, and got following results (from the router), which show that permissions are preserved.
root@OpenWrt:/etc/dump# ls -l
-r--r--r-- 1 root root 0 Sep 2 14:09 file444
-rw------- 1 root root 0 Sep 2 14:08 file600
-rw-r----- 1 root root 0 Sep 2 14:09 file640
-rw-r--r-- 1 root root 0 Sep 2 14:08 file644
-rw-rw---- 1 root root 0 Sep 2 14:09 file660
-rw-rw-rw- 1 root root 0 Sep 2 14:08 file666
-rwx------ 1 root root 0 Sep 2 14:08 file700
-rwxr--r-- 1 root root 0 Sep 2 14:08 file744
-rwxrw---- 1 root root 0 Sep 2 14:09 file760
-rwxrw-r-- 1 root root 0 Sep 2 14:08 file764
-rwxrw-rw- 1 root root 0 Sep 2 14:08 file766
-rwxrwxrwx 1 root root 0 Sep 2 14:07 file777
Sorry about the original portion of the post, which contained (what must be) outdated information.
I think the "root owned" portion of the problem (without "644") will be far more manageable; maybe with a /etc/uci-defaults
script.