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

[Marcus]

It would be nice if ecryptfs-mount-private and ecryptfs-umount-private would emit an upstart event, thus allowing upstart to trigger jobs that require the home dir of a user to be mounted correctly.

[Dustin Kirkland  (kirkland)]

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

[Marcus (m-beyer5)]

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

[Dustin Kirkland  (kirkland)]

Serge/Clint,

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

Dustin

[Serge Hallyn (serge-hallyn)]

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

[Dustin Kirkland  (kirkland)]

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?

[Dustin Kirkland  (kirkland)]

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?

[Marcus (m-beyer5)]

@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

[Serge Hallyn (serge-hallyn)]

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.

[Marcus (m-beyer5)]

Any chance to see this happen in Quantal?