#18818 closed defect (wontfix)
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 |
Description
We've been discussing a small issue with selinux and the VirtualBox RPMs for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1715734
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 (7)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
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:
%files:
http://ftp.rpm.org/max-rpm/s1-rpm-specref-files-list.html
http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list.html
https://docs.fedoraproject.org/ro/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s05.html
https://wiki.mageia.org/en/Packagers_RPM_tutorial#Files_section
https://www.techrepublic.com/article/making-rpms-part-3-installing-files
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"
%install:
https://www.techrepublic.com/article/making-rpms-part-3-installing-files
https://unix.stackexchange.com/questions/180666/rpm-install-section
https://rpm-guide.readthedocs.io/en/latest/rpm-guide.html
https://wiki.mageia.org/en/Packagers_RPM_tutorial#Install_section
https://www.techrepublic.com/article/making-rpms-part-3-installing-files
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:
"3.2.1.14. 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."
comment:3 by , 6 years ago
Component: | other → installer |
---|---|
Host type: | other → Linux |
Keywords: | selinux redhat fedora added |
comment:4 by , 5 years ago
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?
comment:5 by , 5 years ago
closing please re-open if there is someone, a SELinux/RH contact, who's willing to discuss this.
comment:6 by , 5 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:7 by , 5 years ago
Note, one could possibly implement this using the %ghost modifier in the %files section:
https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s05s03.html
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.
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.