Bug 1781796 - [RFE] Anaconda: add option to set mount-options of a filesystem
Summary: [RFE] Anaconda: add option to set mount-options of a filesystem
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: anaconda
Version: 8.1
Hardware: x86_64
OS: Linux
Target Milestone: rc
: 8.0
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
Depends On:
TreeView+ depends on / blocked
Reported: 2019-12-10 15:38 UTC by Andreas Bleischwitz
Modified: 2021-06-24 10:18 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1956659 (view as bug list)
Last Closed:
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4941051 0 None None None 2020-03-31 12:58:56 UTC

Description Andreas Bleischwitz 2019-12-10 15:38:48 UTC
Description of problem:
When partitioning the installation-disk, one is unable to set mount-options for the defined filesystems.

Version-Release number of selected component (if applicable):
Anaconda- (RHEL8.1 ISO)

How reproducible:

Steps to Reproduce:
1. Start graphical installer
2. Select destination-disk
3. Add filesystems
4. Find lack of "mount-options" in the filesystem pane

Actual results:
No option to add mount options for a filesystem

Expected results:
Options for mounting a filesystem editable during partitioning

Additional info:

Comment 2 Martin Kolman 2019-12-10 16:08:26 UTC
Any specific mount options you have in mind ? Maybe these could be added automatically based on the filesystem, its properties or properties of the given system. Or there could be some knobs, that would result in setting those.

Adding a free form entry field for setting mount options verbatim does not seem very ideal to me. If users create multiple filesystems, they would have to set the options multiple types. Options can be long and might have to by typed by hand at install time. Also what to do about invalid options being entered, that would make the mount command fail ?

For that reason it really seems to me like a better idea to find out what's the actual usecase and make the installer handle it right from the start, without the need for manual user interaction.

Comment 3 Andreas Bleischwitz 2019-12-11 08:28:50 UTC
What comes to my mind would be some of the security related ones like "noexec, nodev, nosuid", but some other performance related options may be provided as well like "noatime, nodiratime, relatime, (no)strictatime". I don't think that it would be feasible to parse every filesystem specific option in order to validate them, but some common ones should be allowed as well "uid, gid" - these would need some additional free form entry.

When providing a selection, we may additionally provide some free form entry for options like "*quota". But you are right that this may end up failing to mount that filesystem.
Providing the user a warning text when using the free form entry would increase attention, but this would not avoid that failure during mount.

I'm not sure how you would automatically set the relevant options which are highly dependent to the customers requirements. Automatically adding the security related options on i.e. /home would do no harm in most the cases, but may cause some issues for others. How would we then deal with any other mountpoints like /var, /tmp or /opt?
This should be provided by the user during installation.

The initial idea behind this RFE was caused by selecting a SCAP profile, which required some filesystems to be created - which the user expected to be automatically created, with proper mount-options. While we may take that list of separated mountpoints from the SCAP profile, we would not be able to automatically advise on the size of the filesystems. Adding them to the list of "Mount Point" list of "Add a new mount point" would help, as one would not need to switch between the output of SCAP and partitioning, but this should be another RFE.

Providing the user the ability to adjust the mount-options would introduce some responsibility on the validity of the same, but would on the other hand increase the flexibility during partitioning.

Comment 4 Kyle Walker 2020-03-27 16:26:27 UTC

I agree a free-form entry field isn't ideal, but that might be the most nimble way of achieving this goal. Maybe a free-form list that is validated against the known available mount options? Emitting an error when an unknown value is entered.

Comment 6 Jiri Konecny 2020-06-04 14:36:13 UTC
I'm not really fan of this RFE. It seems to me too advanced to have it in GUI. Partitioning in GUI is confusing even now without new advanced options. 

Could you please use kickstart instead?

Comment 7 Andreas Bleischwitz 2020-06-05 07:20:07 UTC
The reason for raising this RFE is the requirement to set mount-options when applying SCAP profiles. While a scan by using the UI-installer is possible, applying the required changes raised by this profile are not.

So a user may apply a profile, but would not be able to comply to it. If that is not possible, what sense would it make to provide SCAP scanning in the UI?

One way to keep the UI clean could be that an internal list of mountpoints w/ options would be created/extended with the results of the scan.
This list could then be used in the partitioning-UI. The drop-down list of mountpoints would be extended by the list-created, while the mount-options could be applied silently.

I'm also not very liking the idea of over-complicating things.

Comment 8 Jiri Konecny 2020-06-24 13:57:35 UTC
In that case there is a question if this shouldn't be done as part of the addon policy change. Maybe we can provide API for addon (if not already there) to set this options?

Do you think that the Anaconda OSCAP addon is able to change the mount options for you or a user have to decide what exactly they want to change to comply with the policy? In other words is there more than one way how to comply with te policy?

Comment 9 Andreas Bleischwitz 2020-06-24 14:19:48 UTC
I'm not sure how strictly a policy would check in regards to options, but if there is already a "default set" of options for filesystems which are provided in the drop-down box, why not have the OSCAP addon add the related mountpoints/options to that list too?

A user may then easily be able to choose the partitioning on his requirements and also be able to comply to the policy. I don't think we should additionally allow users to set mount-options which could later on cause issues (noexec on /usr/sbin or such).

Comment 10 Jiri Konecny 2020-07-14 10:40:57 UTC
Hi Matej,

Could you please look on this bug and give us some OSCAP statement? For me it seems that the best approach would be that OSCAP addon will add these mount options to the mount-points automatically but I'm not sure on what level you are with the mount point scanning and modifications.

Comment 11 Matěj Týč 2020-07-14 15:33:18 UTC
I am not sure what is the motivation behind this RFE - what exactly "While a scan by using the UI-installer is possible, applying the required changes raised by this profile are not" means exactly?

If the user creates partitions and installs the system with a security profile in mind, OpenSCAP should be able to detect that certain mount options are missing, and it fixes them, so the installed system is compliant. If we take a closer look at the installation process:

1. system is installed based on the installer configuration and the package modifications implied by the selected profile.
2. OpenSCAP performs a scan.
3. Whenever a rule fails, OpenSCAP runs a Bash snippet to fix it, if a snippet exists.
4. OpenSCAP re-scans the rule after the fix has been administered, and the result is either FIXED, or ERROR.

As the system after the installation is a chroot and some fixes require restart to get to their full effect, some rules may show up as false positives. In other words, if you scan the system again after the first boot, you will get less errors.

So is there an issue that the system is not compliant after the installation and remediation? In that case, it could be either a false positive, or a bug in the scanner. Or is it that you don't want to use the addon during the installation for some reason? If so, could you share that reason with us?

Finally, if the Anaconda API allows us to ensure that certain mount options are present, then we will use it, as it is better to get things right as soon as possible. However, we will have to integrate this both to our content and to the addon, so consider this a longer-term solution.

Comment 13 Andreas Bleischwitz 2020-07-24 06:47:04 UTC

the request was raised as my user was installing a system manually via anaconda, applied a OSCAP profile which required some filesystems to be separated. As he did just a standard partitioning, those were flagged as missing. Due to the fact that the information-box showing this message was quite tiny for such messages, he struggled to identify and manually add the missing partitions/mount-points. Additionally some missing mount-options had been reported, but those should be added automatically.

From a user perspective it would be great if the filesystems (or mount-points) which should get separated would show up in the drop-down list within the partitioning page. That way a user would easily be able to identify which filesystems will have to get created.

I agree on that there will most likely never be a automated way to do the partitioning for OSCAP compliance.

Hope that clarifies the reason for this request.


Comment 15 Jan Stodola 2021-04-23 13:26:53 UTC
There are two issues being discussed in this bug:
1) Allow to set mount point / filesystem options in anaconda (comment 0)
2) Make creating of additional mount points (required by OSCAP) easier in the custom partitioning spoke (comment 13)

Let's discuss only 1) in this bug.

Andreas, can you please report a new bug for 2) if this request is still valid?

Comment 16 Jiri Konecny 2021-05-03 15:38:44 UTC
Based on the comment 13 I don't think that the request is to add mount point / filesystem *options* from UI. But to tell user what mount points should be a separate partition and guide them that way to get the requested setup by the policy.

Am I correct Andreas?

Comment 17 Andreas Bleischwitz 2021-05-04 07:29:46 UTC
Hi Jiri,

yes that is correct. My customer was faced by the issue that the OSCAP profile requested separation of filesystems which he was unable to identify in the partitioning layout. He needed to jump back an forth in order to identify the filesystems and create them. Having the requested filesystems/mountpoints listed in the already available drop-down list of Anaconda would ease that job.
As for the options: if we know what should be set as option, just do it accordingly. If the user would be able to manually adjust them - fine, but that's not a requirement. They should make OSCAP happy though ;)

Comment 18 Jan Stodola 2021-05-04 07:59:56 UTC
I've created a new bug 1956659 for easier creation of the required mount points.

Let's discuss only mount point / filesystem mount options in this bug as proposed in comment 15.

Comment 19 Jiri Konecny 2021-05-20 08:59:52 UTC
To tailor the dropdown menu (or maybe even add constrains to Anaconda partitioning checker) based on the policy selected by OSCAP we would have to provide the OSCAP addon an API to be possible to tell us mount point what have to be present or are recommended. Then they should be able to just fill the requirements there.

The question is, if they are possible to tell us what is requested. I'm not familiar of how OSCAP works on this field and these data may not be propagated to the Anaconda OSCAP addon. Could OSCAP developers please confirm that they are able to use API such that from the Anaconda when it's present and if such a solution would be feasible for you?

Comment 20 Jiri Konecny 2021-05-20 09:47:46 UTC
Ahh sorry, I switched the bugs. Matej, please ignore the comment 19 here and let's move the discussion to bug 1956659.

Comment 21 Jiri Konecny 2021-05-20 09:52:27 UTC
So to answer the mount-point options solution. Do I understand it correctly that Anaconda/OSCAP addon now automatically adds these mount options to the installation process so that user don't have to care about these? Or is it blocking the installation process because Anaconda don't have an option how to specify them and the OSCAP addon request these?

Comment 23 Matěj Týč 2021-06-18 14:57:55 UTC
Mount options are not a problem. I think that we can't ensure that mounts are created correctly at the beginning of the installation, but they are remediated later by means of associated Bash remediations.

Comment 24 Jiri Konecny 2021-06-24 10:18:12 UTC
I would like to avoid adding more options to even now complicated partitioning and based on comment 23 it seems it is not required. I would be for closing this bug and look on the solution for bug 1956659.

Note You need to log in before you can comment on or make changes to this bug.