Change Details

A future caller of kern_shm_open() may want to manipulate file flags before the fd gets tossed back to userland. If a `struct file **` is passed, kern_shm_open() will not drop its reference to the `struct file *` on exit and instead passes it through to the caller. It is the caller's responsibility to fdrop.

Now that flags may be set on posixshm, add an argument to kern_shm_open() for the initial seals. To maintain past behavior where callers of shm_open(2) are guaranteed to not have any seals applied to the fd they're given, apply F_SEAL_SEAL for existing callers of kern_shm_open. A special flag could be opened later for shm_open(2) to indicate that sealing should be allowed. We currently restrict initial seals to F_SEAL_SEAL. We cannot error out if F_SEAL_SEAL is re-applied, as this would easily break shm_open() twice to a shmfd that already existed. A note's been added about the assumptions we've made here as a hint towards anyone wanting to allow other seals to be applied at creation.

A future caller of kern_shm_open() may want to manipulate file flags before the fd gets tossed back to userlandNow that flags may be set on posixshm, add an argument to kern_shm_open() for the initial seals. To maintain past behavior where callers of shm_open(2) are guaranteed to not have any seals applied to the fd they're given, apply F_SEAL_SEAL for existing callers of kern_shm_open. A special flag could be opened later for shm_open(2) to indicate that sealing should be allowed. We currently restrict initial seals to F_SEAL_SEAL. If a `struct file **`We cannot error out if F_SEAL_SEAL is passedre-applied, kern_shm_open() will not drop its reference to the `struct file *` on exit and instead passes it through to the calleras this would easily break shm_open() twice to a shmfd that already existed. It is the caller's responsibility to fdropA note's been added about the assumptions we've made here as a hint towards anyone wanting to allow other seals to be applied at creation.