mysql issues...

Russell Coker russell at coker.com.au
Wed May 26 04:17:40 UTC 2004


On Tue, 25 May 2004 12:15, Valdis.Kletnieks at vt.edu wrote:
> Running the mysql command as a mortal user dies:
>
> $ mysql -hlocalhost -u MMMMMM -p MMMMMM
> Enter password:
> ERROR 2002: Can't connect to local MySQL server through socket
> '/var/lib/mysql/mysql.sock' (13)
>
> after throwing this avc message:
> May 24 21:34:19 pink kernel: audit(1085448859.069:0): avc:  denied  {
> search } for  pid=4519 exe=/usr/bin/mysql name=mysql dev=dm-6 ino=129035
> scontext=user_u:user_r:user_t tcontext=system_u:object_r:mysqld_db_t
> tclass=dir

How should we determine who gets mysql client access?  Should we have a 
tunable determining whether we allow userdomain?

> It's not able to search /var/lib/mysql to find the socket...
>
> A (slightly edited) grep shows us:
>
> Does anybody see a good reason why we don't have this too:
>
> mysqld.te: allow mysql_cmd_t mysqld_var_run_t:dir search;
> mysqld.te: allow mysql_cmd_t mysqld_var_run_t:sock_file write;
>
> and add this to mysqld.fc:
>
> /usr/bin/mysql          system_u:object_r:mysql_cmd_t

Why have mysql_cmd_t instead of just allowing user_t directly?  What is the 
benefit in having a domain for client access?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



More information about the fedora-selinux-list mailing list