qemu - Need read/write rights on statedir /var/lib/swtpm-localca for user tss - qemu

I've installed swtpm and added it to a virtual machine using virt-manager (qemu+virsh).
When I'm going to start the machine, a error arises and points to a log file.
The file states:
Need read/write rights on statedir /var/lib/swtpm-localca for user tss.`

The easiest approach I've found is to just give the ownership of that particular folder to that user.
sudo chown -R tss:root /var/lib/swtpm-localca
On my system it has previously stated:
sudo ls -lach /var/lib/swtpm-localca
total 8,0K
drwxr-x--- 2 swtpm root 4,0K Mär 17 11:51 .
drwxr-xr-x 80 root root 4,0K Mär 17 11:51 ..
I do not know what I do break when revoking the user swtmp the access to that folder, but until now it works just smoothly.

Related

Apache doesn't allow to load other files than index.html

Before you ask, I tried to search for similar questions, none of them had precisely my problem.
I'm new at this, and I installed Apache2, PHP5, and MySQL5 on a RasPi running Raspbian.
As needed, I put the index.html in /var/www/html and when I type my Pi's IP alone or followed by /index.html, index.html runs its code properly and all elements appear.
Problem: In addition I put my JS and CSS files in that same folder, as well as a few photos to display.
The browser reads the HTML thoroughly, but doesn't load the thereby linked JS and CSS files nor the images. Putting the files in subfolders also didn't help.
When I type in the IP followed by a /style.css (name of my linked CSS file), I get a 403 Forbidden. The errors log also shows this:
file permissions deny server access: /var/www/html/photo.jpg, referer: http://192.168.178.120/
access to /images/dark.jpg denied because search permissions are missing on a component of the path, referer: http://192.168.178.120/
I tried researching this but nothing helped. When my JS and CSS are inside my HTML, everything works fine except the images
Concluded: Apache doesn't allow the browser to load files other than index.html.
Do you know what the issue might be? Is there a specific folder where I should put my other files? Thanks in advance.
Based on the result from ls, your files are not accessible to Apache.
Short answer:
Run the following two commands:
find /var/www/html -type f -exec chmod 644 {} \;
find /var/www/html -type d -exec chmod 755 {} \;
Longer explanation:
pi#raspberrypi:~ $ ls -l /var/www/html
total 2976
-rw------- 1 pi pi 60146 Jul 23 22:11 bnw.jpg
-rw------- 1 pi pi 202851 Jul 23 22:11 color.jpg
-rw------- 1 pi pi 617185 Jul 23 21:27 dark.jpg
-rw------- 1 pi pi 2028727 Jul 23 22:11 effect.jpg
drwx------ 2 pi pi 4096 Jul 23 21:33 images
-rw------- 1 pi pi 2238 Jul 23 22:11 index.css
-rw-r--r-- 1 pi root 1261 Jul 23 22:11 index.html
-rw------- 1 pi pi 108397 Jul 23 22:11 photo.jpg
-rw------- 1 pi pi 538 Jul 23 22:11 script.js
-rw------- 1 pi pi 2238 Jul 23 21:33 style.css
The symbols at the beginning of the line have the following meaning:
d: indicates a directory
r: means the file/directory is readable
w: means the file/directory is writable
x: means the file/directory is executable
-: means none of the above apply
These symbols are grouped as follows:
drwxrwxrwx
^^^ apply to all users on the system
^^^--- apply to all users in the group that owns the file
^^^------ apply to the user that owns the file
Where it says pi pi it's referring to the file's owner: the user pi in the group pi. Your index.html file is an exception, because it's owned by the group root.
That's not really important for now, other than that you need to realise that Apache usually runs as the user www-data in the group www-data. This varies a bit from system to system, but that's the most common. What that means is that for Apache to be able to access a file, it must be made available to either the www-data user or the www-data group (or both).
In your case, the files are owned by the user pi and the group pi (with the exception of index.html, which is owned by the group root. Since Apache is not that user and is most likely not in either of those groups, that means the file permissions for "all users on the system" must be set correctly for Apache to be able to access the file.
As you can see, index.html is set to be readable for all users on the system:
-rw-r--r-- 1 pi root 1261 Jul 23 22:11 index.html
^^^ all users on the system may read from this file, but may not write and may not execute the file
^^^--- all users in the group "root" may read from this file, but may not write and may not execute the file
^^^------ the user "pi" may read from and write to this file, but may not execute the file
All other files, including the images directory, are only accessible to the "pi" user:
-rw------- 1 pi pi 2028727 Jul 23 22:11 effect.jpg
^^^ all users on the system may not read from, write to or execute this file
^^^--- all users in the group "pi" may not read from, write to or execute this file
^^^------ the user "pi" may read from and write to this file, but may not execute it
So for effect.jpg to be made available to Apache, you need to change the file permissions to this:
-rw----r-- 1 pi pi 2028727 Jul 23 22:11 effect.jpg
^^^ all users on the system (including Apache) may read from this file
To do that, you use the chmod command. There are two ways to flip that permission:
chmod o+r effect.jpg
chmod 604 effect.jpg
chmod o+r means "add 'r' permission to the 'other users' category" (you'd use u+r or g+r to change the user or group permissions).
chmod 604 means "set permissions for the user to 6, group to 0 and others to 4" - where the numbers are a binary sum of the permissions: 1 (executable), 2 (writable), 4 (readable).
Directories need a little more work:
drwx------ 2 pi pi 4096 Jul 23 21:33 images
To allow the file system to actually open a directory and read the files within, it needs to be executable for the user that's trying to access its content. So to allow Apache to read any file from this folder, it will need to have the following permissions:
drwx---r-x 2 pi pi 4096 Jul 23 21:33 images
^^^ all users on the system may read from this directory and execute it
To do this, use the same principle:
chmod o+rx images (other users, add readable and executable permissions)
chmod 705 images (set read(4)+write(2)+execute(1) for owner and read(4)+execute(1) for all other users)
Now, although it's not strictly necessary if the owner and group are the same, it is best practice to make sure that the group has the same permissions as the "all other users" category. So instead of giving files 604 (-rw----r--) and folders 705 (drwx---r-x), it's best practice to give them 644 (-rw-r--r--) and 755 (drwxr-xr-x). If you're working in an environment where multiple developers need to be able to modify the files, they should be in the same user group and best practice is to give the group the same permissions as the owner, so 644 (-rw-rw-r--) and 775 (drwxrwxr-x).
Finally, you don't want to have to change all file permissions manually. This particular project seems to be relatively small, but it's still annoying work. Fortunately, we can use the find command to perform a batch update.
find will list the full contents of the given folder, including subfolders, which you can then filter or perform actions on.
find /var/www/html -type f
This will list all entries within /var/www/html or any subfolders that are a regular file.
find /var/www/html -type d
This will list all entries within /var/www/html or any subfolders that are directories.
We can use -exec to tell find to automatically perform a certain command on each file/folder it finds:
find /var/www/html -type f -exec chmod 644 {} \;
The {} is a placeholder where find will put each filename. The \; is needed to inform find that no further arguments for the -exec command will be provided, so we can optionally add other arguments for find itself.
So the above command will fix the permissions for all files, the following command will fix the permissions for all folders:
find /var/www/html -type d -exec chmod 755 {} \;
After that, Apache should have access to all files and folders in /var/www/html. Keep in mind that, every time you create a new file in that folder, you need to check the permissions and fix it if necessary.

Google Chrome - Crash Dump Location

I'm trying to debug a page in a web app that keeps crashing Chrome ("Aw, snap!" error). I've enabled/disabled automatic crash reporting, tried logging with google-chrome --enable-logging --v=1, (as well as various levels of verbosity), and all I get is a "crash dump ID" in the chrome_debug.log chrome://crashes Shows all of the dump IDs, but no actual dump file
I see other questions referring to reading the dump files, but I can't find the dump files themselves (just the ID).
Grepping for the crash ID in /tmp and ~/.config/google-chrome/ turns up nothing, but the ~/.config/google-chrome/chrome_debug.log shows that something was sent:
--2015-04-06 11:10:00-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 74.125.228.224, 74.125.228.225, 74.125.228.231, ...
Connecting to clients2.google.com (clients2.google.com)|74.125.228.224|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/dev/fd/3’
0K
Crash dump id: 7dac9d5d58258264
Any ideas on where to find the actual file/data that's sent?
Details:
Chrome version: 40.0.2214.111 (Official Build)
Linux Mint 16 (Petra)
Edit: Some extra info:
curtis#localhost:-$ tail -n 5 uploads.log && echo $(pwd)
1428584493,ddc357e4600a49e6
1428584497,7ac16455c152381a
1428589439,d00ad6f5e6426f3d
1428934450,66b3f722430511e8
1428939578,7a2efc2b681515d1
/home/curtis/.config/google-chrome/Crash Reports
curtis#localhost:-$ ll -a
total 12
drwx------ 2 curtis curtis 4096 Apr 6 11:32 .
drwx------ 9 curtis curtis 4096 Apr 13 11:43 ..
-rw------- 1 curtis curtis 3291 Apr 13 11:39 uploads.log
Automatic reporting is enabled...
Thanks!
The *.dmp files are stored in /tmp/, and this has nothing to do with the "Automatic crash reporting" checkbox. The file is also not related to the hash stored in ~/.config/google-chrome/
In ~/.config/google-chrome/Crash Reports/uploads.log:
1429189585,5bddea9f7433e3da
From using , the crash dump file for this particular report was:
chromium-renderer-minidump-2113a256de381bce.dmp
Solution:
root#localhost:-$ mkdir /tmp/misc && chmod 777 /tmp/misc
root#localhost:-$ cd /tmp
root#localhost:-$ watch -n 1 'find . -mmin -1 -exec cp {} /tmp/misc/ \;'
Then, as a regular user (not root):
google-chrome --enable-logging --v=1
Once you see files created by the watch command, run:
root#localhost:-$ ls -l
-rw------- 1 root root 230432 Apr 16 09:06 chromium-renderer-minidump-2113a256de381bce.dmp
-rw------- 1 root root 230264 Apr 16 09:12 chromium-renderer-minidump-95889ebac3d8ac81.dmp
-rw------- 1 root root 231264 Apr 16 09:13 chromium-renderer-minidump-da0752adcba4e7ca.dmp
-rw------- 1 root root 236246 Apr 16 09:12 chromium-upload-56dc27ccc3570a10
-rw------- 1 root root 237247 Apr 16 09:13 chromium-upload-5cebb028232dd944
Now you can use breakpad to work on the *.dmp files.
Google Chrome - Crash Dump Location
To generate the Crash Dump locally,
CHROME_HEADLESS=1 google-chrome
The .dmp files are then stored in ~/.config/google-chrome/Crash Reports
Produce Stack Trace
Check out and add depot_tools to your PATH (used to build breakpad)
git clone https://chromium.googlesource.com/chromium/tools/depot_tools
export PATH=`pwd`/depot_tools:"$PATH"
Check out and build breakpad (using fetch from depot_tools)
mkdir breakpad && cd breakpad
fetch breakpad
cd src
./config && make
To produce stack trace without symbols:
breakpad/src/processor/minidump_stackwalk -m /path/to/minidump
More here https://www.chromium.org/developers/decoding-crash-dumps
Personally Preferred Method
Enable crash reporting:
Chrome menu > Settings > Show advanced settings > Tick "Automatically send usage statistics and crash reports to Google"
Go to chrome://crashes > File bug > Takes you to crbug.com > Complete
report leaving the auto-added report_id field unchanged.
Someone from the Chrome/Chromium team will follow up. They can provide
you with your stack trace and aid at resolving the issue.

Errno 13 Permission denied using Gunicorn

I'm running django on Digital Ocean with gunicorn and nginx. Gunicorn for serving the django and nginx for static files.
Upon uploading a file via website, I cant save to a folder in /home directory. I get [Errno 13] Permission denied.
Please, how do I make the web server to be able have read write access to any arbitrary folder anywhere under /home?
This all depends on the user that your application is running as.
If you check ps aux | grep gunicorn which user the Gunicorn server is running your app as then you can change the chmod or chown permissions accordingly.
ls -lash will show you which user current only owns the folder and what permissions are on the folder you are trying to write to:
4.0K drwxrwx--- 4 username username 4.0K Dec 9 14:11 uploads
You can then use this to check for any issues.
Some docs on changing ownership and permissions
http://linux.die.net/man/1/chmod
http://linux.die.net/man/1/chown
I would advise being very careful to what locations on your disk you give access for the web server to read/write from. This can have massive security implications.
Well, I worked on this issue for more than a week and finally was able to FIGURE IT OUT.
Please follow links from digital ocean , but they did not pinpoint important issues one which includes
no live upstreams while connecting to upstream
*4 connect() to unix:/myproject.sock failed (13: Permission denied) while connecting to upstream
gunicorn OSError: [Errno 1] Operation not permitted
*1 connect() to unix:/tmp/myproject.sock failed (2: No such file or directory)
etc.
These issues are basically permission issue for connection between Nginx and Gunicorn.
To make things simple, I recommend to give same nginx permission to every file/project/python program you create.
To solve all the issue follow this approach:
First thing is :
Log in to the system as a root user
Create /home/nginx directory.
After doing this, follow as per the website until Create an Upstart Script.
Run chown -R nginx:nginx /home/nginx
For upstart script, do the following change in the last line :
exec gunicorn --workers 3 --bind unix:myproject.sock -u nginx -g nginx wsgi
DONT ADD -m permission as it messes up the socket. From the documentation of Gunicorn, when -m is default, python will figure out the best permission
Start the upstart script
Now just go to /etc/nginx/nginx.conf file.
Go to the server module and append:
location / {
include proxy_params;
proxy_pass http<>:<>//unix:/home/nginx/myproject.sock;
}
REMOVE <>
Do not follow the digitalocean aricle from here on
Now restart nginx server and you are good to go.
Change the owner of /home
See actual owner $ ls -l /
f1 f2 f3 f4 f5 f6 f6 f8 f9 f10
- rwx r-x r-x 1 root root 209 Mar 30 17:41 /home
https://www.garron.me/en/go2linux/ls-file-permissions.html
f2 Owner permissions over the file or directory
f3 Group permissions over the file or directory
f4 Everybody else permissions over the file or directory
f6 The user that owns the file or directory
Change folder owner recursively sudo chown -R ubuntu /home/ substitute ubuntu with a non-root user.
Good practices
Use a subdirectory home/ubuntu as server directory, ubuntu folder have ubuntu user as owner.
Set user-owner permissions to all. Your group and other users to read-only sudo chmod -R 744 /home/ubuntu/
I changed the ownership of the file which is containing my images
chown -R www-data: /myproject/media/mainsite/images
Change the path accordingly and also restart server. In my case its apache2 so
sudo service apache2 restart
In my case it was something very simple that was generating a similar error, I just had to check the user who controlled Gunicorn and the user who controlled NGINX, they had different permissions.

Snow Leopard Server MySQL Service and MacPorts MySQL Install Troubles

Trying to back out of a macports mysql installation and return to Snow Leopard Server's built-in MySQL server, but I cannot get it to work.
When I disable macports and enable the built-in service, mysql.sock cannot be found (locate mysql.sock returns nothing). When I re-enable the macport mysql, mysql.sock is found but now I cannot disable the built-in MySQL service.
Every time I try, it just re-enables it.
I have to run the following commands to get MacPorts MySQL to work upon reboots:
sudo launchctl unload -w /Library/LaunchDaemons/org.macports.mysql5.plist
sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist
ln -s /var/mysql/mysql.sock /tmp/mysql.sock
Permissions on /var/mysql are (which is where the built-in service is set to):
drwxr-xr-x 111 _mysql _mysql
Permissions on the macports datadir are:
drwxr-xr-x 116 _mysql _mysql
At one time, according to the access log file for the built-in mysql, it started up correctly (2010). Is there a way to manually disable this service from starting up when I reboot?
I realize how unclear my problem is, but somehow the previous admin got macports mysql tied in with the built-in mysql and I'm having a heck of a time untangling them.
In /Library/LaunchDaemons/ plist-files of the installed applications are located, here's what I have there:
$ ls -l /Library/LaunchDaemons/
-r--r--r-- 1 root wheel 573 Jan 10 18:33 at.obdev.littlesnitchd.plist
-rw-r--r-- 1 root wheel 567 Mar 5 19:02 com.parallels.desktop.launchdaemon.plist
lrwxr-xr-x 1 root admin 74 Jan 20 06:21 org.macports.mysql5.plist -> /opt/local/etc/LaunchDaemons/org.macports.mysql5/org.macports.mysql5.plist
lrwxr-xr-x 1 root admin 74 Oct 14 2011 org.macports.rsyncd.plist -> /opt/local/etc/LaunchDaemons/org.macports.rsyncd/org.macports.rsyncd.plist
And if you'd like to check the MacOS bundled services' config, take a look at /System/Library/LaunchDaemons/.

Trouble running mysql on OSX 10.6 development machine: "ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)"

I've installed MySQL on my personal/development machine using the .dmg package, according to the instructions here: http://dev.mysql.com/doc/refman/5.5/en/macosx-installation-pkg.html including installing the startup item and the preferences pane. And yet, I can't seem to use MySQL at all.
running:
/Library/StartupItems/MySQLCOM/MySQLCOM start
or
/Library/StartupItems/MySQLCOM/MySQLCOM restart
"appears" to work -- in that, it gives me a message like "Starting MySQL database server" -- but afterward, I still can't go into mysql at the command-line, or connect to it in a Rails 2.3.8 application running in script/server. I get the error denoted in the question title.
Also, the MySQL preferences pane doesn't seem to work either. If I click the "Start MySQL Server" button, I'm asked for my password, but then nothing happens -- the pane continues to say that the server is stopped.
(I believe I had a MacPorts version of MySQL installed previously, and it's also possible that there was one built from source at some time in the past -- but I'm reasonably sure I've uninstalled these and deleted all the files having to do with it that I could find.)
I'm also trying mysqld start in terminal. here's the output:
110127 15:40:28 [Warning] Can't create test file /usr/local/mysql-5.5.8-osx10.6-x86_64/data/Lucky-Charm.lower-test
110127 15:40:28 [Warning] Can't create test file /usr/local/mysql-5.5.8-osx10.6-x86_64/data/Lucky-Charm.lower-test
110127 15:40:28 [Note] Plugin 'FEDERATED' is disabled.
mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
110127 15:40:28 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
110127 15:40:28 InnoDB: Initializing buffer pool, size = 128.0M
110127 15:40:28 InnoDB: Completed initialization of buffer pool
110127 15:40:28 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.
Tried following the message about running mysql_upgrade but that just gives me my original error again.
UPDATE:
OK I've been pursuing the theory that it's a permissions problem. Seeing that the datadir was owned by root, I chown -R it to _mysql. In response to Mike, here's where that now stands:
$ ls -al /usr/local/mysql-5.5.8-osx10.6-x86_64
total 296
drwxr-xr-x 16 root wheel 544 Dec 3 12:53 .
drwxrwxr-x 12 root staff 408 Jan 27 14:38 ..
-rw-r--r-- 1 root wheel 17987 Dec 3 11:58 COPYING
-rw-r--r-- 1 root wheel 12388 Dec 3 11:58 INSTALL-BINARY
-rw-r--r-- 1 root wheel 113534 Dec 3 11:58 README
drwxr-xr-x 44 root wheel 1496 Dec 3 12:53 bin
drwxr-xr-x 9 _mysql wheel 306 Jan 27 16:46 data
drwxr-xr-x 4 root wheel 136 Dec 3 12:53 docs
drwxr-xr-x 47 root wheel 1598 Dec 3 12:53 include
drwxr-xr-x 12 root wheel 408 Jan 27 14:38 lib
drwxr-xr-x 4 root wheel 136 Dec 3 12:53 man
drwxr-xr-x 19 root wheel 646 Jan 27 14:38 mysql-test
drwxr-xr-x 3 root wheel 102 Dec 3 12:53 scripts
drwxr-xr-x 32 root wheel 1088 Dec 3 12:53 share
drwxr-xr-x 28 root wheel 952 Dec 3 12:53 sql-bench
drwxr-xr-x 16 root wheel 544 Dec 3 12:53 support-files
I was trying to do mysqld start in the Terminal because it was the only thing giving me anything that seemed like meaningful error message output (see https://gist.github.com/799436) but I'm told by folks in #mysql that that's not intended to be run directly (and if I try sudo mysqld start i get a message bitching me out for trying to run mysql as root).
I seem to have something working now: mysqld_safe & successfully gets a MySQL server running. What still doesn't work is the "normal" method of starting up the server (the Startup Item or Preferences Pane)
... leading someone in #mysql to tell me that apparently MySQL is fine, it's the startup item that's borked.
Ok there were several things, mostly having to do with permissions/ownership, that were tried to make the binary-installed MySQL work nicely.
You may need to make sure that the startup item is owned by root:
sudo chown -R root:wheel /Library/StartupItems/MySQLCOM
Maybe you need a /etc/my.cnf file with this in it:
[mysqld]
socket=/tmp/mysql.sock
datadir=/usr/local/mysql/data
You might need to fill in these variables in /usr/local/mysql/support-files/mysql.server (the line will be there with blank values):
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
(see can't start MySql in Mac OS 10.6 Snow Leopard regarding the above)
That may be enough to do it, but if not, try making sure the mysql user (_mysql) can write to the data directory (owns it and has write permissions to everything in it).
Anyway, now the Preferences Panel and Startup Item actually seem to work for me.
After going over this a second time on another machine, I've made some edits and removed some unnecessary bit from what I answered yesterday.
Overall here's what I suggest you do to get the binary-installed MySQL working nice in OSX 10.6. Warning, you might end up deleting any databases you already had in the first couple steps, but as this is intended to be for your development machine, that shouldn't be any big deal. Back stuff up with mysqldump first if you must.
Make sure you don't have a mysql server running right now: ps aux | grep mysql will show you their processes. Stop it with mysqladmin shutdown or if that won't work because something is borked, sudo kill the process numbers.
Remove any prior installed versions of mysql -- check port list installed, check for a homebrew-installed one, sudo find / -name mysql looking for compiled-from-source ones and delete them, whatever it takes. You could even remove the startup item by deleting the /Library/StartupItems/MySQLCOM directory if you want.
Run the mysql-whatever-version.pkg install package
Test it by typing sudo mysqld_safe & at the terminal. If you get "command not found," add /usr/local/mysql/bin to your path and try again. If you get any scary error messages, check for a /etc/my.cnf file as described above and try again. If it still doesn't work, then maybe try recursively chowning and chmoding the /usr/local/mysql/data directory to make sure _mysql can write to it. Once you get it to appear to start up OK, enter mysql at terminal. If you get a MySQL command prompt, all is well (enter exit to get out of it) -- in fact, if you get anything other than the ol' "Can't connect to local MySQL server through socket" then you can conclude that the MySQL server works -- shut down or kill the server and move on.
Next we'll install the startup item. Run MySQLStartupItem.pkg
Test the startup item at the terminal by entering sudo /Library/StartupItems/MySQLCOM/MySQLCOM start. It will give you a message claiming that it is starting up the server, but if it's unsuccessful it won't give you any indication, so try going into mysql again to test that the server is running. If so, enter sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop to stop the server (and to test that the startup item can stop the server as well as start it :D) If it didn't work, try making the settings described above in /usr/local/mysql/support-files/mysql.server. If that still doesn't do it, try the bit up at the top about sudo chown -R root:wheel /Library/StartupItems/MySQLCOM.
Once that works, run/install the MySQL.prefPane. This should give you a MySQL item in your System Preferences near the bottom, and if you go in there, you should see a button that you can click which will stop/start the MySQL server. Try it, and if it doesn't work by now, I'm not sure what else I can tell you.
I had experienced the same error after removing my old mac ports and installing mysql in a new mac ports directory ( a new /opt/local ).
I fixed it by setting the correct permissions for the mysql directories in the ports tree:
chown -R _mysql:_mysql /opt/local/var/db/mysql5
chown -R _mysql:_mysql /opt/local/var/run/mysql5/
chmod -R 755 /opt/local/var/run/mysql5
I'm not sure if the chmod was needed. Of course ports had already done the job of creating the _mysql user and group.