Ticket #18818 (closed defect: wontfix)

Opened 16 months ago

Last modified 11 months ago

Please add an empty /var/log/vbox-setup.log file to VirtualBox Fedora RPMs

Reported by: hansg Owned by:
Component: installer Version: VirtualBox 6.0.10
Keywords: selinux redhat fedora Cc:
Guest type: other Host type: Linux


We've been discussing a small issue with selinux and the VirtualBox RPMs for Fedora:

The problem is that the default selinux policy does not like it when initscripts create *new* files under /var/log.

If I understand Lukas correctly, then if you can add an empty /var/log/vbox-setup.log to the RPM, the problem will go away.

Doing so is easy, just add:

touch $RPM_BUILD_ROOT/var/log/vbox-setup.log

to the %install section of the spec file and add /var/log/vbox-setup.log to the %files section.

Change History

comment:1 Changed 16 months ago by fbatschu

From an architectural perspective, the proposed change does not look very plausible, more like a band-aid then a solution for what appears to be a design choice or problem wit SE Linux policies.

You can have an arbitrary number of 3rd party software packages running under SE Linux conditions, should they all start to package creation of empty log files? Packaging the creation of empty log files does not look like a typical use case for any packaging system.

Thinking about it, what should be the semantics of a package install, specifically the final proposed

touch $RPM_BUILD_ROOT/var/log/vbox-setup.log

if that operation fails? Is the entire package installation then considered failed by the packaging system, or is it considered partially successful by the packaging system? If the latter, you will still experience the current failure pattern later on during first start of VBox.

Also the referenced bug does not contain any materials or pointers to describe those SE Linux policies about file creation semantics and constraints in /var/log. it would be certainly of benefit for a solution if that could be provided.

comment:2 Changed 16 months ago by fbatschu

I've looked into the RPM packaging background on this issue for a bit, here are the details regarding the proposed change, just in case we have to do it that way:


From there:

"The %files list indicates which files on the build system are to be packaged. The list consists of one file per line. If a directory is specified, by default all files and subdirectories will be packaged."

"%files The list of files that will be installed in their final resting place in the context of the target system."

"The %files section holds a list of all the files that RPM should install from the package. This list should be exhaustive, so that the RPM system knows exactly what your package installs. There are some options, though, to name all the files within a directory to help with packages containing hundreds of files. In the default case, each line under the %files section names a separate file with its full path"


From there:

"%install Command or series of commands for copying the desired build artifacts from the %builddir (where the build happens) to the %buildroot directory (which contains the directory structure with the files to be packaged). This usually means copying files from ~/rpmbuild/BUILD to ~/rpmbuild/BUILDROOT and creating the necessary directories in ~/rpmbuild/BUILDROOT. This is only run when creating a package, not when the end-user installs the package. See Section 5.1.7, “Working with SPEC files” for details."

"%install Command or series of commands used to actually install the various artifacts into a resulting location in the FHS. Something to note is that this is done within the relative context of the %buildroot (more on that later)."

"in the %install section, you are supposed to install all your files in the %{buildroot] directory; just the way they will be installed on the final system."

"This section will contain the script responsible for actually installing the package in the simulated installation directory: %{buildroot}, or the equivalent $RPM_BUILD_ROOT. It will contain all the commands necessary to make the software ready to run on the user's system."

The proposal is to just add:

touch $RPM_BUILD_ROOT/var/log/vbox-setup.log

to the %install section of the spec file.

So the touch in the build area (which is when the %install section is executed) is unlikely going to have the proper set of owner and permissions that we want to have on the final install destination, thus we'd also need to add an %attr or %defattr% directive to the %files section to manage proper install permissions.

As %files section will pull into the binary RPM package from the build directory. So the %files section would need to make sure to use a permission directive for the empty log %file using%attr and %defattr when deploying the package on the destination:

The LFS tells us about /var/log:

" The /var/ Directory Since the FHS requires Linux to mount /usr/ as read-only, any programs that write log files or need spool/ or lock/ directories should write them to the /var/ directory. The FHS states /var/ is for: ...variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files. System log files, such as messages and lastlog, go in the /var/log/ directory. The /var/lib/rpm/ directory contains RPM system databases. Lock files go in the /var/lock/ directory, usually in directories for the program using the file. The /var/spool/ directory has subdirectories for programs in which data files are stored."

Last edited 16 months ago by fbatschu (previous) (diff)

comment:3 Changed 16 months ago by fbatschu

  • Keywords selinux redhat fedora added
  • Host type changed from other to Linux
  • Component changed from other to installer

comment:4 Changed 15 months ago by fbatschu

is there any information forthcomming regarding the details of the problematic SELinux policies? Instructions to reproduce the problem (I dont know what prerequisites one needs to establish the SELinux barriers required for the problem to happen)? Also I see absolutely no technical statement or assessment from someone on the RH/SELinux side, I have raised a couple of points initially why I think a change to VBOX is probably the wrong approach?

Last edited 15 months ago by fbatschu (previous) (diff)

comment:5 Changed 15 months ago by fbatschu

closing please re-open if there is someone, a SELinux/RH contact, who's willing to discuss this.

comment:6 Changed 15 months ago by fbatschu

  • Status changed from new to closed
  • Resolution set to wontfix

comment:7 Changed 11 months ago by fbatschu

Note, one could possibly implement this using the %ghost modifier in the %files section:

Another special modifier, %ghost, tells the rpm command that the file should not be included in the package. You can use this to name the needed attributes for a file that the program, when installed, will create. For example, you may want to ensure that a program’s log file has certain attributes. 
Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use