Webserver: chrooted PHP gives mysql.sock error when attempting to reach mysql

Question

Here's the scenario: I have developed an Android application that uses other app's ContentProvider. I have the required bits in AndroidManifest.xml file, but using the other app's content is only a feature - the user does not need to install the third-party app and it makes perfect sense to ignore it.

The problem is: when the user decides to install the third-party app to use my software fully, she has no chance granting my app the missing permission, because it wasn't displayed during installation time (Android had no clue about it), and Android won't ask for it again until the software is updated or reinstalled. My app cannot simply start to use the permission as if it was always granted, because:

java.lang.SecurityException: Permission Denial: opening provider X from ProcessRecord{...} (...) requires perm.Y or perm.Z

That's perfectly reasonable, I can catch the exception and the app will continue to work as if the third-app wasn't installed, but it'd be counter-intuitive for the user. The only solution (not quite acceptable) I have found is to ask the user to reinstall my application to be able to grant the permission to the other app.

Solution 1

I solved my own issue. Jailkit couldn't create a hard link reference to mysqld.sock, as Ubuntu stores /var/run in tmpfs, which appears to the system to be a separate partition (which breaks hardlink functionality). I instead am now mounting /var/run/mysqld in the jail now, like so: mount --bind /var/run/mysqld /home/jail/var/run/mysqld/

Solution 2

How about using as host value 127.0.0.1? It uses TCP connection which doesn't write socket (unlike localhost value on unix).

Solution 3

Remounting using --bind for the chroot looks like a workable suggestion. However, IMHO connecting to MySQL using a TCP socket (127.0.0.1) seems cleaner, more secure and less likely to go wrong.

The reason I say that is that various sources including http://blog.dispatched.ch/postfix-and-mysql-debian/ and https://stackoverflow.com/questions/11389214/postfix-cant-connect-with-mysql-table-when-using-unix-socket-postmap-succeeds suggest adding to the fstab:

 /var/run/mysqld /home/jail/var/run/mysqld bind defaults,bind 0 0

Be cautious with that: Debian at least cleans out /var/run on reboot, so the mount will fail at boot time, and so will your service. Of course you could instead use:

 /var/run /home/jail/var/run bind defaults,bind 0 0

Comments

[Jon L.]

That's a valid suggestion, but my concern is that /home/jail could be "volatile". Any suggestion on how to modify /etc/jailkit/jk_init.ini to force jailkit to create a hardlink to the mysqld.sock file, or some other jailkit compatible solution that doesn't risk the MySQL server if the jail is (for instance) completely deleted and rebuilt?

[SkarabePL]

Thank you. It's a very nasty security hole, the same as it would be if an app could request for permissions in advance (as in my case) and using it without any user confirmation once the "true" application is installed.

[CommonsWare]

@SkarabePL: Agreed, which is why I published the PermissionUtils class to help detect problems.

[Joó Ádám]

Wasting system resources for no benefit.

[BurninLeo]

Works like a charm. But really ... it there no easier solution? Why does MySQL need a socket at all, when the communication runs via localhost:3306, anyway?

[BurninLeo]

Okay, found out it IS easier (serverfault.com/a/337844/100194), just use an IP address (127.0.0.1) as MySQL host in mysqli_connect(), instead of localhost. This requires slightly more resources, but the difference should be negligible.

[gone]

Is it possible to script this when creating the jail?