File ownership and permissions

When mkifs includes files, directories and symbolic links in an OS image, by default these items inherit the development host's user ID, group ID, and permissions, on Linux. You can override these settings through buildfile attributes. On Windows, you should always specify these attributes, to ensure your OS image items have the correct ownership and permissions.

Other, ephemeral, items brought into the image don't all acquire user IDs, group IDs, or permissions in the same way as directories, files and symbolic links, however:

Symbol files: The owner of symbol files from the [+keeplinked] attribute on bootstrap binaries is the owner running mkifs. On Linux, the permission bits for these symbol files are inherited from the user's current umask. On Windows, mkifs might guess at the permissions, so you should set them explicitly, as demonstrated below.
Inline files: For inline files, unless otherwise specified, the following default user ID, group ID, and permissions are used on Linux: 0:0:0666. On Windows, mkifs might guess at the permissions, so you should set them explicitly, as demonstrated below.
Directories: For directories created with [type=dir], unless otherwise specified, the following default user ID, group ID, and permissions are used on Linux: 0:0:0755. This applies also to directories created automatically as part of another item's target path. On Windows, mkifs might guess at the permissions, so you should set them explicitly, as demonstrated below.

Changing user ID, group ID, and permissions

To change the user ID, group ID, and permissions for files when they are included in the image, prefix the item name with the appropriate attributes in the buildfile. For example:

[uid=0 gid=0 perms=0666] file1
[uid=5 gid=1 perms=a+xr] file2

These lines mark the first file (file1) as owned by root (the user ID 0), group 0, and readable and writable by all (the mode of octal 666). The second file (file2) is marked as being owned by user ID 5, group ID 1, and executable and readable by all.

Note:

When running on a Windows host, mkifs can't get the execute (x), setuid (“set user ID”), or setgid (“set group ID”) permissions from the file. You need to use the perms attribute to specify the access permissions explicitly.

You might also need to use the uid and gid attributes to set the ownership correctly. To determine whether or not a utility needs to have the setuid or setgid permission set, see its entry in the Utilities Reference.

For more information about utilities to control ownership and permissions on target systems, see “File ownership and permissions” in the QNX Neutrino User's Guide, and the mkifs uid, gid, and perms attributes.

When you combine attributes, place them all inside one set of square brackets, as in the example above: [uid=0 gid=0 perms=0666] file1. See “Buildfile syntax” for more information about attributes and buildfile syntax.

If you want to set permission fields for multiple files, you can specify the attributes on a single line, followed by the list of files. For example:

[uid=5 gid=1 perms=0666]
file1
file2
file3
file4

which is equivalent to:

[uid=5 gid=1 perms=0666] file1
[uid=5 gid=1 perms=0666] file2
[uid=5 gid=1 perms=0666] file3
[uid=5 gid=1 perms=0666] file4

To set the permissions for directories, you must use a different attribute:

[uid=5 gid=1 dperms=0755] dir1

Note: When running on a Windows host, mkifs can't get the execute (x), setuid (“set user ID”), or setgid (“set group ID”) permissions from the directory. You need to use the dperms attribute to specify these permissions explicitly, and might also need to use the uid and gid attributes to set the ownership correctly. For more information, see the mkifs uid, gid, and dperms attributes.