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 <
Hello.
Post by Kyle Sallee#2016/02/07 20:15:09# profile=3 mode=enforcing granted=no
(global-pid=6458)
Post by Kyle Salleetask={ pid=23261 ppid=26622 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0
fsuid=0
Post by Kyle Salleefsgid=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) ----------
Post by Kyle SalleeHow 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.
Post by Kyle Sallee# 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.