Bug 1781796

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.

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.

@MKolman,

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.

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?

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.

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?

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).

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.

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.

Hi,

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.

/Andreas

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?

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?

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 ;)

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.

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?

Ahh sorry, I switched the bugs. Matej, please ignore the comment 19 here and let's move the discussion to bug 1956659.

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?

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.

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.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.