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 permissions, and the user ID and group ID are set to those of the host file (or to 0 on Windows). You can override these settings through buildfile attributes.

Note:

Windows neither provides a umask nor properly reflects the file ownership and permissions. On a Windows development host, you should always specify these attributes, to ensure your OS image items have the correct ownership and permissions.

For some OS image items described below, the different behavior for Windows is summarized but otherwise, the descriptions apply to all development host OSs.

Some items brought into the image don't acquire ownership and permissions in the same way as files, directories, and symbolic links, however:

Inline files

Unless otherwise specified, the default user ID and group ID are those of the user running mkifs (or 0 on Windows), and the default permissions are 0666 (or 0644 on Windows).

Directories with no host equivalent

There are two cases when directories that don't exist on the host will be available on the target:

When [type=dir] is specified in front of a file path in the buildfile; we refer to such directories as explicitly created directories.

For these directories, unless otherwise specified, the default user ID, group ID, and permissions are 0:0:0755.
When a directory gets emulated by procnto because it's part of the target path for a buildfile item. For example, if dir/file is specified in the buildfile but dir isn't, dir gets emulated at runtime by procnto; we refer to such directories as virtual directories.

For these directories, you can't set their ownership and permissions; their settings are chosen by procnto. If you need to assign specific ownership and permissions for such directories in your target image, you must create them explicitly.

For symbol files generated from the [+keeplinked] attribute on bootstrap binaries, the owner is the user running mkifs. The permission bits for these symbol files are inherited from the user's current umask. On Windows, permissions might be dictated by the OS. These files are not brought into the target image; they are kept on the host and used for debugging.

For all binaries in the bootstrap section (procnto-* etc.), unless otherwise specified in the buildfile, the default user ID and group ID are 0, and the default permissions are those of the host file ORed with 0111. The startup-* bootstrap binary doesn't have file attributes because it precedes the filesystem and thus, isn't part of it.

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:

On a Windows host, mkifs can't get any file attribute except for the write (w) bit, which is based on Windows' read-only file attribute. Also, mkifs must guess at whether the execute (x) bit should be set based on whether the file is an ELF file of an appropriate type.

You need to use the perms attribute to specify the access permissions explicitly. You 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 a directory, you must use a different attribute:

[uid=5 gid=1 dperms=0755] dir1=/some/host/dir

Sub-directories are unaffected.

Note: On a Windows host, mkifs can't get the execute (x) bit, sticky bit, read permissions, 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 use the uid and gid attributes to set the ownership correctly. For more information, see the mkifs uid, gid, and dperms attributes.