On 8/12/20 3:21 PM, Stephen Smalley wrote:
On Wed, Aug 12, 2020 at 3:15 PM Daniel Burgener <dburgener@xxxxxxxxxxxxxxxxxxx> wrote:Separating the cleanup from the creation will simplify two things in future patches in this series. First, the creation can be made generic, to create directories not tied to the selinux_fs_info structure. Second, we will ultimately want to reorder creation and deletion so that the deletions aren't performed until the new directory structures have already been moved into place. Signed-off-by: Daniel Burgener <dburgener@xxxxxxxxxxxxxxxxxxx> --- security/selinux/selinuxfs.c | 41 ++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 14 deletions(-) diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c index 131816878e50..fc914facb48f 100644 --- a/security/selinux/selinuxfs.c +++ b/security/selinux/selinuxfs.c @@ -355,6 +355,9 @@ static int sel_make_classes(struct selinux_fs_info *fsi, static struct dentry *sel_make_dir(struct dentry *dir, const char *name, unsigned long *ino); +/* declaration for sel_remove_old_policy_nodes */ +static void sel_remove_entries(struct dentry *de); + static ssize_t sel_read_mls(struct file *filp, char __user *buf, size_t count, loff_t *ppos) { @@ -509,11 +512,35 @@ static const struct file_operations sel_policy_ops = { .llseek = generic_file_llseek, }; +static void sel_remove_old_policy_nodes(struct selinux_fs_info *fsi) +{ + u32 i; + + /* bool_dir cleanup */ + for (i = 0; i < fsi->bool_num; i++) + kfree(fsi->bool_pending_names[i]); + kfree(fsi->bool_pending_names); + kfree(fsi->bool_pending_values); + fsi->bool_num = 0; + fsi->bool_pending_names = NULL; + fsi->bool_pending_values = NULL; + + sel_remove_entries(fsi->bool_dir); + + /* class_dir cleanup */ + sel_remove_entries(fsi->class_dir); + + /* policycap_dir cleanup */ + sel_remove_entries(fsi->policycap_dir);This one shouldn't have its entries removed anymore.
Yes, you're right. This didn't come up in my testing because this part of the function gets removed in the fourth patch in the series anyways. Given that most of this patch actually gets lost in the fourth patch, that's probably an indication that I should rethink having this patch in the series at all. I'll come up with something cleaner for version 2.
-Daniel
