Messages in this thread | | | Date | Fri, 14 Jul 2006 14:52:30 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC][PATCH 3/6] SLIM main patch |
| |
Quoting Dave Hansen (haveblue@us.ibm.com): > > +static void revoke_file_wperm(struct slm_file_xattr *cur_level) > > +{ > > + int i, j = 0; > > + struct files_struct *files = current->files; > > + unsigned long fd = 0; > > + struct fdtable *fdt; > > + struct file *file; > > + > > + if (!files || !cur_level) > > + return; > > + > > + spin_lock(&files->file_lock); > > + fdt = files_fdtable(files); > > + > > + for (;;) { > > + i =j * __NFDBITS; > > + if ( i>= fdt->max_fdset || i >= fdt->max_fds) > > + break; > > + fd = fdt->open_fds->fds_bits[j++]; > > + while(fd) { > > + if (fd & 1) { > > + file = fdt->fd[i++]; > > + if (file && file->f_dentry) > > + do_revoke_file_wperm(file, cur_level); > > + } > > + fd >>= 1; > > + } > > + } > > + spin_unlock(&files->file_lock); > > +} > > This is an awfully ugly function ;) > > Instead of actually walking the fd table and revoking permissions, would > doing a hook in generic_write_permission() help? It might be easier to > switch back and forth.
Or, would using security_file_permission(), which is called on each read and write to an open file, suffice? Would it perform as well as this way?
-serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |