Messages in this thread | | | Date | Thu, 23 Mar 2023 13:44:59 -0400 | From | Johannes Weiner <> | Subject | Re: [PATCH v2 3/3] sched/psi: allow unprivileged polling of N*2s period |
| |
On Thu, Mar 23, 2023 at 09:55:11AM -0700, Suren Baghdasaryan wrote: > On Thu, Mar 23, 2023 at 3:34 AM Domenico Cerasuolo > > @@ -1254,16 +1262,19 @@ int psi_show(struct seq_file *m, struct psi_group *group, enum psi_res res) > > } > > > > struct psi_trigger *psi_trigger_create(struct psi_group *group, > > - char *buf, enum psi_res res) > > + char *buf, enum psi_res res, struct file *file) > > { > > struct psi_trigger *t; > > enum psi_states state; > > u32 threshold_us; > > + bool privileged; > > u32 window_us; > > > > if (static_branch_likely(&psi_disabled)) > > return ERR_PTR(-EOPNOTSUPP); > > > > + privileged = cap_raised(file->f_cred->cap_effective, CAP_SYS_RESOURCE); > > I missed one detail here. We are moving the cap check from open() to > write(). That might break potential users which open the file from a > process with that cap and then pass that FD to an unprivileged process > to create the trigger by writing to that file. I'm not aware of any > use of such a pattern but it is possible there are such users. > With this change such users would have to delegate trigger creation to > the privileged process too and the received FD would be used only for > polling. IMHO that's a safer pattern because triggers are created by > the privileged process.
Oh, it's checking file->f_cred, which is set up at open(). So if the opener is privileged, the write can be delegated to an unprivileged process.
But I agree that this is subtle and could use a comment.
This was a usecase specifically requested by Christian, actually.
| |