umount options are incorrectly treated as mount options

Bug #1403968 reported by Tyler Hicks
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AppArmor
Triaged
Medium
Unassigned
apparmor (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

apparmor_parser is treating options on umount rules as mount options. The flags used in mount(2) are entirely different than the flags used in umount2() and apparmor_parser knows nothing about the umount2() flags (MNT_FORCE, MNT_DETACH, MNT_EXPIRE, UMOUNT_NOFOLLOW).

This can be demonstrated by trying to compile a policy, with apparmor_parser version 2.9.1, containing a umount rule that is conditional on the "force" option:

  $ echo "/t { umount options=force, }" | ./apparmor_parser -qQ; echo $?
    unsupported mount options
  1

Now we'll use a mount flag in the umount rule:

  $ echo "/t { umount options=nosuid, }" | ./apparmor_parser -qQ; echo $?
  0

The umount rule with a umount option fails to compile but the umount rule with a mount option compiles. This is not the intended behavior and it should be the other way around.

Tags: aa-parser
Tyler Hicks (tyhicks)
Changed in apparmor (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
tags: added: aa-parser
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Ping?

Just wondering whether this is fitting into wily timeframe.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

Hi Serge - I think it is still a possibility in the wily time frame.

Also, I've just confirmed that nobody snuck a fix into the 2.10 release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.