Fantastic explanation. Does seem like a glibc bug. I awoke thinking, "glibc no sei hazu desu."
In an imperfect world; sometimes imperfect solutions work best. However, if that solution is always safe and if unlink directory attempts always fail then perhaps within Tomoyo a hard coded default rule should exist? Perhaps by an example and explanation in documentation future inquiries might be mitigated. https://tomoyo.osdn.jp/2.5/policy-specification/exception-policy-syntax.html.en#acl_group https://tomoyo.osdn.jp/2.5/policy-specification/domain-policy-syntax.html.en#file_unlink https://tomoyo.osdn.jp/2.5/policy-specification/domain-policy-syntax.html.en#file_rmdir For good locations the above might suffice. At least for me, for acl_group a better use has not been conjectured. Among software the glibc remove function use might be rare. For years Tomoyo rules have been used. After remove function use in self authored software only the bug was encountered. If the report added to an already high stack of bug reports then sorry. While the help is appreciated; a Tomoyo rule design help request was unexpected was unintended. For a trifling request, sorry. Watakushi no tsumanai shitsumon no koto ga sumimasen. Tetsudatte arigatou gozaimasu. For the help thanks. Tested results with acl_group 0: acl_group 0 file unlink /\{\*\}/ acl_group 0 file unlink \*:/\{\*\}/ Success! /tmp/anything/a /tmp/anything/b/ By the remove function both above directories were removed. To glibc software authors; should the bug be reported? By glibc authors a kernel bug would be probably surmised. Maybe the fault was mine alone? On Mon, Feb 8, 2016 at 3:18 AM, Tetsuo Handa < from-tomoyo-users...@i-love.sakura.ne.jp> wrote: > Hello. > > Kyle Sallee wrote: > > > > > > #2016/02/07 20:15:09# profile=3 mode=enforcing granted=no > (global-pid=6458) > > task={ pid=23261 ppid=26622 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 > fsuid=0 > > fsgid=0 } path1={ uid=0 gid=0 ino=131127 major=8 minor=19 perm=0755 > > type=directory } path1.parent={ uid=0 gid=0 ino=131126 perm=0755 } > > <kernel> //free > > file unlink /tmp/anything/p/ > > > > /tmp/anything/p/ is a directory. > > /tmp/anything/p/ ga directory desu. > > > > By the Tomoyo domain removal should be allowed. > > Tomoyo domain ni yoru to dekiru hazu desu. > > > > From the remove function; the request was not granted. > > Remove function kara nozomu tokoro wo narimasen. > > > > While from the rmdir function; the request was granted. > > Keredomo rmdir function kara; Tomoyo ha itashimasu. > > > It seems that remove() function unconditionally tries to delete it > using unlink(), and retries using rmdir() when unlink() failed with EISDIR. > > ---------- sample program ---------- > #include <stdio.h> > > int main(int argc, char *argv[]) { > remove("/tmp/anything/p"); > return 0; > } > ---------- sample program ---------- > > ---------- strace output (without TOMOYO) ---------- > unlink("/tmp/anything/p") = -1 EISDIR (Is a directory) > rmdir("/tmp/anything/p") = 0 > ---------- strace output (without TOMOYO) ---------- > > > How unexpected? > > Okashii to omoimasu. > > > > Might a bug exist? > > Mushi ga aru kamo shiremasen? > > > > Indeed, it is an unexpected error code for userspace. > > Technically, security_path_unlink() hook (used by TOMOYO and AppArmor) > is called before may_delete() which performs EISDIR check is called. > While on the other hand, security_inode_unlink() hook (used by SELinux > and Smack) is called after may_delete() is called. > > Calling security_path_unlink() before may_delete() is a limitation > (tolerable > approach for VFS maintainers) for using security_path_unlink() hook. Thus, > if we want to avoid this error, TOMOYO needs to return EISDIR if the file > passed to security_path_unlink() is a directory. > > Since /tmp/anything/p/ is a directory, rmdir() needs to be used for > removing it. I think this denial log will be gone if you add > > acl_group $N file unlink / > acl_group $N file unlink /\{\*\}/ > acl_group $N file unlink \*:/ > acl_group $N file unlink \*:/\{\*\}/ > > to exception policy, for TOMOYO will grant removing directories using > unlink() and may_delete() will reject such requests with EISDIR. > > > # uname -r > > 4.1.15 > > > > For the help thanks. > > osewani narimasu. > > > > Tomoyo ga suki deshou deshou! > > Tomoyo is great, right! > > > > Arigatou goazaimasu. > > Thanks. > > Thank you for your report. >
_______________________________________________ tomoyo-users-en mailing list tomoyo-users-en@lists.osdn.me http://lists.osdn.me/mailman/listinfo/tomoyo-users-en
