[Debian Bug #715483] permission check too naive: doesn't work with ACLs

[k0lter]

This bug report is a copy of https://bugs.debian.org/715483

[Leo 'costela' Antunes]

Dear Maintainer,

incron's UserTable::MayAccess is too naive and reinvents the wheel when checking permissions on a watched dir. Since it only manually checks for uid/gid matching, it silently ignores folders that can actually be accessed according to the set ACLs (thought it does warn about "access denied" while reloading the incrontab).

For instance, the current handling of /media is done with per-user subdirs which all belong to root:root, but get ACLs set appropriately for the actual intended owner. This means incrontabs handling removable media don't work. I'm not sure why /media gets handled like this, but I hope you agree incron's inability to deal with ACLs is a problem regardless of this particular case's merits.

Cheers

[costela]

For the record: my naive attempt at solving this involved using seteuid()/setegid() and euidaccess() to check for file access. That at least doesn't reinvent the wheel, but it still doesn't solve my original issue because glibc's euidaccess() doesn't support ACLs either (see comment "XXX Add support for ACLs")

Another possible idea would be fork()+setuid()+access(), but that would mean one fork per event, which could be infeasible. @ar- , if you think it might still be a good idea to switch to using glibc's euidaccess() anyway (who knows, maybe glibc will support ACLs someday...), I can create a PR for that.

[pmontrasio]

I run into this now on Ubuntu 16.04 while trying to detect newly mounted drives with /media/my-username IN_CREATE /my/script $#

An approach would be not to check the access rights when the new incrontab is saved. Just notify the event to my script and let the file system decide if I can access those files. But I'm not familiar with the code so maybe you need to make those checks in advance to be able to get the events.

As a workaround I had to sudo chmod 755 /media/my-username (a chgrp would be fine too) but if I'm not wrong that second level directory doesn't always exist. Furthermore there should be a valid reason for the use of the ACL on that directory.

[costela]

@pmontrasio the problem with this approach is that it creates (at least) an information leak. Unpriviledged users could create scripts that could create watches and monitor what's happening in folders they don't actually have access to.

As for your workaround, the chgrp sounds slighly safer and I also couldn't find an actual reason for that ACL. My theory is that it's related to multi-seat environments, where two logged-in users should have access to the same plugged-in media, but I honestly didn't bother to check that theory.