ecryptfs-(u-)mount-private should emit an upstart event

Can you post a patch, a branch, or at least instructions on how to do so?

The easiest way would propably be to just call initct[1][2] with some meaningful parameters after the (u-)mount is successful, eg.

initctl emit ecryptfs-mounted-private USER=$USER MOUNTPOINT=$MOUNTPOINT SOMEKEY=$SOMEVALUE

[1] http://manpages.ubuntu.com/manpages/precise/en/man8/initctl.8.html
[2] http://upstart.ubuntu.com/cookbook/#initctl

Serge/Clint,

What do you think about this suggestion? Is it a reasonable idea? Any security concerns?

Dustin

It does make the manual use of setuid-root 'mount.ecryptfs_private' scarier...

On Mon, Jan 9, 2012 at 8:31 AM, Serge Hallyn <email address hidden> wrote:
> It does make the manual use of setuid-root 'mount.ecryptfs_private'
> scarier...

Serge, what do you mean?

On Sun, Jan 8, 2012 at 8:46 AM, Marcus <email address hidden> wrote:
> initctl emit ecryptfs-mounted-private USER=$USER MOUNTPOINT=$MOUNTPOINT
> SOMEKEY=$SOMEVALUE

Does this have to be executed as the root user?

@6
AFAIK yes, because upstart uses dbus methods which are by default restricted to the root user, so currently only the systemuser can register and trigger upstart jobs. Changing that will require a new upstart dbus configuration which will hopefully become the default in the future. See also http://upstart.ubuntu.com/cookbook/#user-job and /etc/dbus-1/system.d/Upstart.conf

Quoting Dustin Kirkland (<email address hidden>):
> On Sun, Jan 8, 2012 at 8:46 AM, Marcus <email address hidden> wrote:
> > initctl emit ecryptfs-mounted-private USER=$USER MOUNTPOINT=$MOUNTPOINT
> > SOMEKEY=$SOMEVALUE
>
> Does this have to be executed as the root user?

Yes, it does. And mount.ecryptfs-private is setuid-root, so it can be
executed by non-root. It's probably no big deal, but it means that
$USER, $MOUNTPOINT, and $SOMEVALUE will be passed to root-owned jobs,
and in the past perhaps have been assumed to come from ('trusted') root
tasks. I don't know how carefully those get sanitized along the chain.

It may be no big deal, but any time something which in the past may have
assumed 'trusted' input is going to be handed untrusted input, it's worth
worrying about.

Any chance to see this happen in Quantal?