Now that we have created a user for the package, we still have to decide where it has permission to write. This is done, as seen previously, using the --gen option. Ideally, we would like the package not to be able to overwrite other package files in the install directories, nor remove them. There is a permission bit on UNIX systems that achieve just that: the sticky bit.

The sticky bit prevents unprivileged user (i.e the package user in our case) from changing or removing a file that they don't own. It is typically used in directories like /tmp, where everyone has write access.

The idea is that you are going to give write access in the install directory to all package users, but since the sticky bit is on, they won't be able to damage files from other packages.

How do we give write access to all package users ? In short, we put every package user in a given group, called the install group, as they are created. When --gen is invoked, all urpkg do is to change the directory's group to this install group, enable write access for this group and turn on the sticky bit.

Something similar happens for shared files, although we don't need the sticky bit here, and a different group is used: the shared group.

The install group is “urpkgrp-install” and the shared group is “urpkgrp-group”. Every package user is a member of those groups once it is created. This means it is possible for any package to write to a shared file or put files in an installation directory. Keep this in mind when you make a file shared for example.

As we have already seen, all files created by a package user have by default its name as owner and its group as group. Why do we need to have both ? In fact we don't, for simple cases. As a matter of fact, urpkg will consider any file that has the package user as its owner or as its group. The nice thing about this is that you can easily change the owner or group of any file of the package.

For example, suppose you are installing the sudo program. It obviously needs to be suid root by the very nature of the task it performs. In that case, you can just change its owner to root and set the suid bit as usual. The file will still be detected as belonging to the sudo package since its group still has the package user name of sudo.

Sometimes it may happen that both the group and the owner have to be changed. This is the case for some daemon that uses both the suid and the sgid bit. Fcron is an example of this. In that case, you can still force the file to belong to the package using --add without any --change-owner or --change-group option. The file name will then be added to a text file containing a list of supplementary files belonging to fcron. The disadvantage here is that you cannot move or remove the file without having urpkg complaining, so don't do it unless you really have to. More details are given in the section called “Owned and added files”