On Mon, 27.06.11 08:39, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
I am tempted to say that this behaviour makes a lot of sense, but I can
also understand if you'd prefer it not to return an error exit code.
To understand this better, what is afuse, and why does it return EPERM
for us even though we are root?
afuse is a userspace helper for the fuse filesystem. In my case, I use
it to automount sshfs
afuse sets up a temp mount point for each automounted fs in /tmp, and
since this is done using credentials, I guess that root is not
permitted to inspect them:
root@desktop /tmp/afuse-CAUhnW # ls -la
ls: cannot access server: Permission denied
total 0
drwx-- 1 sofar sofar 10 Jun 25 16:20 .
drwxrwxrwt 1 root root 7888 Jun 27 08:30 ..
d? ? ? ??? server
root@hannah /tmp/afuse-CAUhnW # stat server
stat: cannot stat `server': Permission denied
In general, I'm not sure what to do with this case. The error had me
wondering if tmpfile.d did complete, which wasn't entirely clear from
the error message in the service. On top of that, I'd say that it was
successful in the first place, it just encountered something strange
on the way. Worth a syslog message for sure, but I'm not entirely sure
this should result in the service being marked as 'failed', which
reads a lot differently.
I have now modified systemd git to not exit with a failure code in this
case. In the context of fuse and selinux (where even the root user might
get EPERM or EACCES) it's probably wise to avoid any confusion and log
the files we cannot access but not return a non-zero exit code. We will
still exit with an error if there's an error in the config files
however.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
