[systemd-devel] BUG: systemd tmpfiles-clean.service trips over afuse stuff in /tmp

[Lennart Poettering]

On Mon, 27.06.11 08:39, Kok, Auke-jan H (auke-jan.h.kok at 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 at 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 at 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.