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