Hello, Am Donnerstag, 28. November 2013 schrieb Seth Arnold: > On Tue, Nov 05, 2013 at 05:34:58AM -0800, John Johansen wrote:
> > diff --git a/fs/open.c b/fs/open.c > > index d420331..9505fc5 100644 > > --- a/fs/open.c > > +++ b/fs/open.c > > @@ -387,6 +387,10 @@ retry: > > if (error) > > goto out; > > > > + error = security_path_chdir(&path); > > + if (error) > > + goto dput_and_out; > > + > > > > error = inode_permission(path.dentry->d_inode, MAY_EXEC | > > MAY_CHDIR); > > if (error) > > goto dput_and_out; Hmm, does that mean that first the AppArmor permissions are checked and then the file/directory permissions? I reported some time ago that the audit.log contains stuff that would be denied by file/directory permissions anyway (which also means logging it more confusing than useful ;-) and the answer was that this (IMHO buggy) behaviour is caused by the kernel. It might be a good idea to check the file/directory permissions first, and, _if_ access would be allowed, ask AppArmor via the security hook. > > @@ -419,6 +423,10 @@ SYSCALL_DEFINE1(fchdir, unsigned int, fd) > > > > if (!S_ISDIR(inode->i_mode)) > > goto out_putf; > > > > + error = security_path_chdir(&f.file->f_path); > > + if (error) > > + goto out_putf; > > + > > > > error = inode_permission(inode, MAY_EXEC | MAY_CHDIR); Same here. Regards, Christian Boltz -- Machen wir einen Club "utf-8 geplagte Perl-Programmierer" auf? [Bernhard Walle in suse-programming] -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
