FiveM Database User และ Permissions คืออะไร? วิธีสร้าง MariaDB User แยกจาก root และกำหนดสิทธิ์ให้ oxmysql อย่างปลอดภัย

August 13, 2026

FiveM Database User คือบัญชีที่ oxmysql ใช้ Login เข้า MySQL/MariaDB เพื่อให้ Resources อ่านและเขียนข้อมูล เช่น Characters, Vehicles, Settings และข้อมูลถาวรอื่นของ Server

แม้ตัวอย่างติดตั้งหลายแห่งจะใช้ root เพื่อให้ตั้งค่าได้ง่าย แต่สำหรับ Production Server แนวทางที่ปลอดภัยกว่าคือสร้าง Database User แยกสำหรับ FiveM และให้เฉพาะ Privileges ที่ Application จำเป็นต้องใช้ ตามหลัก Least Privilege โดย MariaDB แนะนำไม่ให้ใช้ root สำหรับงาน Application ตามปกติ และให้สร้าง Dedicated User ที่มีสิทธิ์จำกัดแทน.

ตัวอย่าง Architecture:

FXServer
↓
oxmysql
↓
FiveM Database User
↓
MariaDB
↓
fivem Database

แทน:

FXServer
↓
oxmysql
↓
root
↓
สิทธิ์ทุกอย่างบน Database Server

① MariaDB User คืออะไร

MariaDB ใช้ Account ในรูปแบบ:

'user'@'host'

ตัวอย่าง:

'fivem_app'@'localhost'

หรือ:

'fivem_app'@'10.0.0.20'

MariaDB เก็บทั้ง User และ Host เป็นส่วนหนึ่งของ Identity ของ Account ดังนั้น User ชื่อเดียวกันแต่เชื่อมจาก Host ต่างกันสามารถเป็นคนละ Account ได้.

② ทำไม FiveM ไม่ควรใช้ root ตลอด

root เป็น Administrative Account ที่มักมี Privileges สูงมาก

ถ้า Connection String ของ FiveM ใช้:

root

แล้ว Credential รั่ว ผลกระทบอาจกว้างกว่าการรั่วของ User ที่เข้าถึงได้เฉพาะ Database ของ FiveM

MariaDB Security Guidance แนะนำหลัก Least Privilege และระบุให้หลีกเลี่ยงการใช้ root สำหรับงาน Application ทั่วไป.

③ Least Privilege คืออะไร

หลักคิดคือ:

ให้สิทธิ์เท่าที่ Application จำเป็นต้องใช้จริง และไม่มากกว่านั้น

ตัวอย่าง:

FiveM Resource ต้องใช้
SELECT
INSERT
UPDATE
DELETE

ไม่จำเป็นต้องใช้
CREATE USER
DROP USER
GRANT OPTION
SUPER/Admin privileges

MariaDB แนะนำให้ Grant เฉพาะ Privileges ขั้นต่ำที่ User ต้องใช้ในการทำงาน.

④ วิธีสร้าง Database User สำหรับ FiveM

ตัวอย่าง:

CREATE USER
    'fivem_app'@'localhost'
IDENTIFIED BY
    'CHANGE_THIS_PASSWORD';

CREATE USER เป็นคำสั่งมาตรฐานของ MariaDB สำหรับสร้าง Account ใหม่ และ Account ที่สร้างใหม่จะยังไม่มี Application Privileges จนกว่าจะมีการ GRANT.

⑤ อย่าใช้ Password จากตัวอย่างจริง

ตัวอย่าง:

CHANGE_THIS_PASSWORD

ต้องเปลี่ยนเป็น Password ที่แข็งแรงและไม่ซ้ำกับ Account อื่น

และอย่าโพสต์ Password จริงใน:

Discord
GitHub
Forum
Screenshot
Log

MariaDB Security Guidance แนะนำ Strong และ Unique Passwords สำหรับ Database Accounts.

⑥ Host ใน CREATE USER สำคัญอย่างไร

ตัวอย่าง:

CREATE USER
    'fivem_app'@'localhost'
IDENTIFIED BY
    'PASSWORD';

หมายถึง Account สำหรับ Connection ที่ Match กับ Host localhost

MariaDB Account ถูกระบุจากคู่:

User + Host

ไม่ใช่ Username อย่างเดียว.

⑦ FXServer กับ Database อยู่เครื่องเดียวกัน

สามารถออกแบบ User เช่น:

CREATE USER
    'fivem_app'@'localhost'
IDENTIFIED BY
    'PASSWORD';

แล้ว Connection String ใช้ Local Database Host ตาม Environment จริง

แนวคิดคือจำกัด Account ให้ใช้จาก Host ที่จำเป็นแทนเปิดกว้างโดยไม่มีเหตุผล

⑧ FXServer กับ Database อยู่คนละเครื่อง

สมมติ:

FXServer
10.0.0.20

MariaDB
10.0.0.30

Database Account อาจต้องอนุญาต Host ของ FXServer ตาม Network Design เช่น:

CREATE USER
    'fivem_app'@'10.0.0.20'
IDENTIFIED BY
    'PASSWORD';

การกำหนด Host ที่แคบกว่าช่วยจำกัดว่า Account สามารถ Authenticate มาจากไหนตามระบบ Account ของ MariaDB.

⑨ ใช้ '%' ได้ไหม

MariaDB สามารถใช้ Wildcard ใน Host Matching ได้ในระบบ Account/Privilege

แต่:

'fivem_app'@'%'

หมายถึงอนุญาต Host กว้างมากกว่าการระบุ FXServer Host โดยตรง

สำหรับ Production ถ้ารู้ Source Host อยู่แล้ว ควรใช้ Host Constraint ที่แคบเท่าที่ Infrastructure อนุญาต แทนเปิดกว้างโดยไม่จำเป็น ตามหลัก Least Privilege.

⑩ GRANT คืออะไร

GRANT ใช้เพิ่ม Privileges หรือ Roles ให้ MariaDB Account

MariaDB ระบุว่า GRANT สามารถใช้กำหนดสิทธิ์ให้ Account และสามารถใช้ SHOW GRANTS ตรวจสิทธิ์ที่ Account มีอยู่.

ตัวอย่าง:

GRANT
    SELECT,
    INSERT,
    UPDATE,
    DELETE
ON
    `fivem`.*
TO
    'fivem_app'@'localhost';

⑪ `fivem`.* หมายถึงอะไร

ตัวอย่าง:

ON `fivem`.*

หมายถึง Privileges ภายใน Database:

fivem

ทุก Table ที่อยู่ภายใต้ Scope นั้น

MariaDB มี Privilege หลายระดับ เช่น Global, Database และ Table Level ดังนั้นสามารถจำกัดสิทธิ์ไว้เฉพาะ Database ของ FiveM แทน *.* ทั้ง Server ได้.

⑫ ทำไม `.` ต้องระวัง

ตัวอย่าง:

GRANT ALL PRIVILEGES
ON *.*
TO 'fivem_app'@'localhost';

Scope:

*.*

=
ทุก Database
ทุก Object ที่เกี่ยวข้องตาม Privilege

กว้างกว่า:

fivem.*

อย่างมาก

Application Account จึงควรถูก Scope เท่าที่จำเป็น.

⑬ FiveM ต้องใช้ ALL PRIVILEGES ไหม

ไม่จำเป็นสำหรับทุก Server

ให้ดูว่า Resources ต้องทำอะไรจริง

ถ้าระหว่าง Gameplay ใช้เพียง:

SELECT
INSERT
UPDATE
DELETE

ก็ไม่ควรให้ Administrative Privileges เพิ่มโดยไม่มี Requirement

แต่ Resource บางตัวอาจมี Auto Migration และต้อง:

CREATE
ALTER
INDEX

ช่วงติดตั้งหรือ Update

ดังนั้น Permissions ต้องออกแบบตาม Resource Stack จริง ไม่ควร Copy ชุดเดียวให้ทุก Server

⑭ SELECT Permission คืออะไร

ใช้อนุญาตอ่านข้อมูล

ตัวอย่าง:

SELECT
    `id`,
    `firstname`
FROM
    `characters`;

หาก FiveM Resource ต้อง Load Character Records ก็ต้องมี Read Permission ที่สอดคล้องกับ Query

MariaDB รองรับ Privilege Assignment ผ่าน GRANT ใน Scope ต่างๆ.

⑮ INSERT Permission คืออะไร

ใช้เพิ่มข้อมูลใหม่

เช่น:

INSERT INTO `player_settings`
    (`identifier`, `theme`)
VALUES
    (?, ?);

Resource ที่สร้าง Persistent Records ต้องมี Permission ที่อนุญาต Operation นั้น

⑯ UPDATE Permission คืออะไร

ใช้แก้ข้อมูลที่มีอยู่

เช่น:

UPDATE `player_settings`
SET `theme` = ?
WHERE `identifier` = ?;

Resource ที่ Save Player State หรือ Settings จึงมักต้องใช้ UPDATE

⑰ DELETE Permission คืออะไร

ใช้ลบ Rows

เช่น:

DELETE FROM `temporary_data`
WHERE `id` = ?;

ถ้า Resource ไม่เคย Delete Records ก็ไม่จำเป็นต้อง Grant DELETE เพียงเพราะเห็น Server อื่นให้

ใช้ Requirement จริงเป็นหลัก

⑱ CREATE Permission คืออะไร

อนุญาตสร้าง Database Objects ตาม Scope ที่ได้รับ

Resource ที่ Auto-create Tables ตอนติดตั้งอาจต้องใช้

แต่ Gameplay Resource ที่ Schema ถูกสร้างเรียบร้อยแล้วอาจไม่ต้องใช้ CREATE ตลอด Runtime

⑲ ALTER Permission คืออะไร

อนุญาตแก้โครงสร้าง Table เช่น:

ALTER TABLE ...

Resource ที่มี Automatic Migration อาจต้องใช้ ALTER

แต่ ALTER เป็นสิทธิ์ที่กว้างกว่า CRUD ปกติ จึงควรให้เมื่อ Architecture ต้องการจริง

⑳ DROP Permission ต้องระวังมาก

DROP สามารถลบ Objects เช่น Table ตาม Scope/สิทธิ์ที่กำหนด

สำหรับ Runtime Application User ถ้า Resource ไม่ต้อง Drop Tables ก็ไม่ควรเพิ่ม Privilege นี้โดยไม่มีเหตุผล

หลัก Least Privilege มีประโยชน์มากกับสิทธิ์ประเภท Destructive Operations.

㉑ GRANT OPTION คืออะไร

MariaDB ระบุว่าผู้ที่จะ GRANT Privileges ให้ Account อื่นต้องมี GRANT OPTION และมี Privileges ที่กำลัง Grant อยู่เอง.

FiveM Application User ทั่วไปไม่จำเป็นต้องมี:

GRANT OPTION

เพราะ Resource ไม่ควรไปสร้างหรือแจก Permissions ให้ Database Users อื่นระหว่าง Gameplay

㉒ CREATE USER Permission จำเป็นกับ FiveM ไหม

ปกติไม่จำเป็นสำหรับ Gameplay Resources

MariaDB ระบุว่า CREATE USER ใช้สร้าง Database Accounts ใหม่.

FiveM Resource ส่วนใหญ่ต้องจัดการ Gameplay Data ไม่ใช่ Database Administrative Accounts

㉓ ชุด Permission แบบ Runtime

ตัวอย่างเชิงหลักการ:

GRANT
    SELECT,
    INSERT,
    UPDATE,
    DELETE
ON
    `fivem`.*
TO
    'fivem_app'@'localhost';

เหมาะเป็นจุดเริ่มคิดสำหรับ Resource Stack ที่ Schema ถูกติดตั้งเรียบร้อยแล้วและ Gameplay ต้องทำ CRUD เท่านั้น

แต่ต้องตรวจ Resources ของ Server จริงก่อนนำไปใช้

㉔ ชุด Permission สำหรับ Migration

ถ้า Resource ต้อง Migration Schema อัตโนมัติ อาจต้องเพิ่มสิทธิ์ เช่น:

CREATE
ALTER
INDEX

เฉพาะที่ Migration ต้องใช้

อีกแนวทางหนึ่งคือแยก:

Admin/Migration User

กับ:

Runtime FiveM User

เพื่อให้ Runtime Credential ไม่มี Schema-changing Privileges หลัง Migration เสร็จ

㉕ แยก Migration User ดีอย่างไร

Architecture:

Database Administrator
↓
Migration User
↓
ALTER / CREATE / INDEX

FiveM Runtime
↓
fivem_app
↓
SELECT / INSERT / UPDATE / DELETE

ช่วยลดสิทธิ์ของ Credential ที่ FiveM ใช้ทุกวัน

นี่เป็นการประยุกต์หลัก Least Privilege กับ Deployment Workflow.

㉖ SHOW GRANTS คืออะไร

ใช้ดูว่า MariaDB User มี Privileges อะไร

ตัวอย่าง:

SHOW GRANTS
FOR
    'fivem_app'@'localhost';

MariaDB ระบุว่า SHOW GRANTS แสดง GRANT Statements/Privileges ของ Account หรือ Role ที่ระบุ.

㉗ ตรวจ Permissions ก่อนแก้ Access Denied

เมื่อ FiveM ขึ้น:

Access denied

อย่าเริ่มด้วย:

GRANT ALL PRIVILEGES ON *.* ...

ทันที

ให้ใช้:

SHOW GRANTS
FOR 'fivem_app'@'localhost';

แล้วตรวจว่าขาด Permission ไหนจริง

㉘ REVOKE คืออะไร

REVOKE ใช้ถอน Privileges ที่เคยให้ Account

MariaDB มีคำสั่ง REVOKE สำหรับลบ Privileges และมีรูปแบบถอน Privileges หลาย Scope.

ตัวอย่าง:

REVOKE DROP
ON `fivem`.*
FROM 'fivem_app'@'localhost';

เหมาะเมื่อพบว่า Runtime User มีสิทธิ์เกินความจำเป็น

㉙ ลด Permission หลัง Migration ได้ไหม

ได้ และเป็นแนวทางที่ดี

ตัวอย่าง:

ก่อน Migration
CREATE
ALTER
INDEX
SELECT
INSERT
UPDATE
DELETE

หลัง Migration
SELECT
INSERT
UPDATE
DELETE

ใช้ REVOKE ถอน Schema-changing Privileges ที่ไม่จำเป็นหลัง Update.

㉚ ต้อง FLUSH PRIVILEGES หลัง GRANT ไหม

เมื่อจัดการ Accounts/Privileges ผ่าน Account Management Statements เช่น CREATE USER, GRANT และ REVOKE ควรใช้คำสั่งเหล่านี้โดยตรงแทนแก้ Grant Tables เอง

MariaDB Documentation ระบุว่าระบบ Privileges ควรจัดการผ่าน Statements ที่เกี่ยวข้อง เช่น GRANT มากกว่าการแก้ System Tables โดยตรง.

จึงไม่ควรสร้าง Workflow โดยแก้ mysql.* Tables ด้วย SQL UPDATE แบบตรงๆ

㉛ อย่าแก้ mysql.user ด้วยมือ

MariaDB ระบุว่า System Privilege Tables สามารถ Query ได้ แต่แนะนำใช้ GRANT และ Account Management Statements ในการจัดสิทธิ์แทน.

ใช้:

CREATE USER
GRANT
REVOKE
SHOW GRANTS

อ่านง่ายและปลอดภัยกว่า

㉜ Connection String ใช้ Dedicated User อย่างไร

เดิม:

set mysql_connection_string "mysql://root:PASSWORD@127.0.0.1:3306/fivem"

เปลี่ยนเป็น:

set mysql_connection_string "mysql://fivem_app:PASSWORD@127.0.0.1:3306/fivem"

oxmysql Documentation ระบุให้กำหนด mysql_connection_string ก่อน Start Resources และใช้ set สำหรับ Configuration นี้.

㉝ ตัวอย่าง Connection String แบบ Key/Value

set mysql_connection_string "user=fivem_app;password=PASSWORD;host=127.0.0.1;port=3306;database=fivem"

oxmysql รองรับทั้ง URI และ Key/Value Connection String Formats.

㉞ เปลี่ยนจาก root เป็น User ใหม่ต้อง Restart อะไร

หลังแก้ mysql_connection_string ควรให้ oxmysql/FiveM Database Layer Initialize ด้วย Credential ใหม่ตาม Maintenance Procedure

อย่าเปลี่ยน Credential กลาง Production โดยไม่มี Test

Flow ที่ปลอดภัยกว่า:

Create User
↓
Grant
↓
Test Connection
↓
Backup Config
↓
Maintenance
↓
เปลี่ยน Connection String
↓
Start/Restart ตาม Dependency
↓
ตรวจ Console

㉟ ทดสอบ User ใหม่ก่อนใช้จริง

ก่อนเปลี่ยน FiveM ให้ลอง Login Database ด้วย Account นั้นจาก Host ที่ FXServer ใช้

จากนั้นทดสอบ:

SELECT
INSERT
UPDATE
DELETE

ใน Test Table/Environment ตาม Permissions ที่ตั้งไว้

ถ้า Login ไม่ได้ อย่าเพิ่งเปลี่ยน Production Connection String

㊱ Access Denied หลังเปลี่ยนจาก root

ตรวจ 3 ส่วน:

① User ถูกไหม
② Host Match ไหม
③ Privileges ถูกไหม

เพราะ MariaDB Account Identity ประกอบด้วยทั้ง User และ Host.

㊲ `'fivem_app'@'localhost'` กับ `'fivem_app'@'%'` เหมือนกันไหม

ไม่

เป็น Account Definitions ที่มี Host Scope ต่างกัน

MariaDB ใช้คู่ User/Host เป็น Identity ของ Account.

ดังนั้น:

fivem_app@localhost

อาจมี Privileges คนละชุดกับ:

fivem_app@%

㊳ Database อยู่ Remote แล้ว Access Denied

อาจเกิดจาก:

User มีเฉพาะ @localhost

แต่ FXServer เชื่อมมาจาก:

10.0.0.20

MariaDB จึง Match Account ตาม Host Rules ไม่ตรง

ต้องสร้าง/Grant Account ที่ตรงกับ Network Architecture แทนการเปิด % โดยอัตโนมัติ

㊴ Security Layer มีมากกว่า Database User

Database User เป็นเพียงหนึ่งชั้น

Production Security ยังมี:

Firewall
Network Binding
Database Authentication
User Host Scope
Privileges
Connection String Protection
Server File Permissions

การใช้ Dedicated User ไม่ได้แทน Firewall หรือ Network Security

㊵ Database Port ไม่ควรเปิดทั้งโลก

แม้ Account มี Password แข็งแรง การจำกัด Network Access ยังสำคัญ

ตัวอย่าง:

Internet
X
↓
Database

FXServer IP
✓
↓
Database

ช่วยลด Surface ที่ Database ต้องรับ Connection Attempts

㊶ Connection String เป็น Secret

ไฟล์:

server.cfg

อาจมี:

Database Username
Database Password
Host
Database Name

ดังนั้นอย่าเผย Config ทั้งไฟล์ต่อสาธารณะโดยไม่ Mask Secrets

㊷ Git Repository ต้องระวัง

หลีกเลี่ยง Commit:

server.cfg
.env
database config

ที่มี Production Password ลง Public Repository

ถ้าต้องแชร์ Configuration Example ให้ใช้:

CHANGE_ME

แทน Credential จริง

㊸ FiveM Resource ควรรู้ Password ไหม

Gameplay Resource ไม่จำเป็นต้องมี Password แยกอยู่ใน Lua File

Resource ควรเรียก:

MySQL.query.await(...)

ผ่าน oxmysql

ส่วน Connection Credential อยู่ใน Server Configuration ที่ Database Layer ใช้

㊹ อย่าใส่ Password ใน client.lua

client.lua ไม่ควรมี Database Secrets

Architecture ที่ถูก:

Client
↓
Server Event
↓
Server Validation
↓
oxmysql
↓
Database

ไม่ใช่ให้ Client มี Database Credential

㊺ Database User ไม่ได้แทน Event Security

ถึง fivem_app จะมี Privileges จำกัด แต่ Network Event ยังต้อง Validate

ตัวอย่าง Player ส่ง:

character_id = 999

Server ยังต้องตรวจ:

Character เป็นของ Player หรือไม่
Request ถูกต้องหรือไม่
Player มี Permission หรือไม่

ก่อน Query

Database Least Privilege ลด Impact ที่ Database Layer แต่ไม่ได้ทำ Gameplay Authorization ให้เอง

㊻ Resource ถูก Exploit แล้ว Limited User ช่วยอย่างไร

สมมติ Resource Bug ทำให้เกิด SQL Operation ที่ไม่ควรเกิด

ถ้า User มีเฉพาะ:

SELECT
INSERT
UPDATE
DELETE

Database Account จะไม่มี Schema/Admin Privileges บางประเภทที่ไม่ได้ Grant

นี่คือประโยชน์เชิง Defense-in-depth ของ Least Privilege.

㊼ แต่ DELETE ยังอันตรายไหม

ใช่

ถ้า Gameplay Resource ต้องใช้ DELETE ก็ยังสามารถลบ Rows ภายใน Scope ที่ได้รับอนุญาตได้

Least Privilege ไม่ได้ทำให้ Bug ไม่มีผล

มันมีหน้าที่จำกัด ขอบเขตสูงสุดของสิทธิ์ ให้แคบลง

㊽ ถ้า Resource ไม่ต้อง DELETE ควรถอนไหม

ควรพิจารณา

หากตรวจ Resources ทั้งหมดแล้วไม่มี Query DELETE ที่จำเป็น การไม่ Grant DELETE เป็น Least-Privilege Design ที่ดีกว่า

แต่ต้องทดสอบก่อน Production เพราะ Framework บางตัวอาจมี Cleanup Logic ที่ต้อง Delete Records

㊾ ตาราง Permissions ที่ควรรู้

Privilege	ใช้ทำอะไร
`SELECT`	อ่าน Rows
`INSERT`	เพิ่ม Rows
`UPDATE`	แก้ Rows
`DELETE`	ลบ Rows
`CREATE`	สร้าง Objects
`ALTER`	เปลี่ยน Schema
`DROP`	ลบ Objects
`INDEX`	จัดการ Index ตาม Scope
`GRANT OPTION`	ให้สิทธิ์ต่อ Accounts อื่น

MariaDB จัดการ Privileges ผ่าน GRANT และอนุญาตให้กำหนด Scope ได้หลายระดับ.

㊿ วิธีตรวจว่า FiveM ต้องการ Permission อะไรจริง

เริ่มจาก:

Resource SQL Files
↓
Queries ใน Server Code
↓
Migration Files
↓
Runtime Queries

แยกเป็น:

Runtime
vs
Deployment/Migration

จากนั้นจึงออกแบบ Grants

อย่าดูแค่ Resource หนึ่งตัวถ้า Database ถูกใช้ร่วมทั้ง Framework

51. Runtime Query Audit

ค้นหา SQL Keywords เช่น:

SELECT
INSERT
UPDATE
DELETE
CREATE
ALTER
DROP

ใน Server-side Resources

แล้วทำรายการ:

Framework A
→ SELECT INSERT UPDATE DELETE

Resource B
→ SELECT UPDATE

Migration C
→ ALTER CREATE INDEX

จะเห็นว่า Runtime User ต้องมีอะไรจริง

52. Auto Migration ทำให้ Permission ซับซ้อนขึ้น

Resource บางตัวอาจตรวจ Schema ตอน Start และสร้าง/แก้ Table เอง

กรณีนี้ถ้า Runtime User ไม่มี:

CREATE
ALTER

Resource อาจ Start ไม่ครบ

ทางเลือกคือ:

ให้สิทธิ์ตาม Requirement

หรือ:

Run Migration ด้วย Administrative Deployment User
แล้วใช้ Runtime User จำกัดสิทธิ์

ต้องดู Architecture ของ Resource จริง

53. SHOW GRANTS หลังตั้งค่า

หลัง Grant ให้ตรวจ:

SHOW GRANTS
FOR 'fivem_app'@'localhost';

อย่าพึ่งจำว่าคำสั่งก่อนหน้ารันอะไรไป

SHOW GRANTS เป็นวิธีมาตรฐานของ MariaDB สำหรับดู Privileges ปัจจุบันของ Account.

54. ตัวอย่าง Runtime User แบบจำกัด Database

CREATE USER
    'fivem_app'@'localhost'
IDENTIFIED BY
    'STRONG_PASSWORD';

GRANT
    SELECT,
    INSERT,
    UPDATE,
    DELETE
ON
    `fivem`.*
TO
    'fivem_app'@'localhost';

SHOW GRANTS
FOR
    'fivem_app'@'localhost';

นี่เป็น Template เชิงหลักการ ต้องปรับ Host และ Privileges ให้ตรงกับ Resource Stack จริง.

55. ถ้า Resources ต้อง CREATE/ALTER

อาจเพิ่ม:

GRANT
    CREATE,
    ALTER,
    INDEX
ON
    `fivem`.*
TO
    'fivem_app'@'localhost';

เฉพาะเมื่อ Resource Requirements ยืนยันว่าต้องใช้

หลัง Migration หากไม่จำเป็นอีกแล้วสามารถพิจารณา REVOKE.

56. ตัวอย่างถอน ALTER

REVOKE ALTER
ON
    `fivem`.*
FROM
    'fivem_app'@'localhost';

จากนั้นตรวจ:

SHOW GRANTS
FOR
    'fivem_app'@'localhost';

MariaDB รองรับทั้ง REVOKE และ SHOW GRANTS สำหรับการจัดการ/ตรวจสิทธิ์.

57. DROP USER ใช้เมื่อไร

เมื่อ Database Account ไม่ต้องใช้งานแล้ว สามารถลบ Account ด้วย:

DROP USER
    'old_fivem_user'@'localhost';

MariaDB รองรับ DROP USER สำหรับนำ Account ออกจากระบบ Authentication.

อย่าลบ Account ปัจจุบันก่อนทดสอบว่า FiveM ใช้ User ใหม่ได้สมบูรณ์

58. วิธีเปลี่ยนจาก root ไป Dedicated User

ใช้ Flow:

① Backup server.cfg
② สร้าง fivem_app
③ Grant สิทธิ์ที่ต้องใช้
④ SHOW GRANTS
⑤ Test Login
⑥ Test SELECT
⑦ Test INSERT/UPDATE
⑧ Test Resource บน Staging
⑨ Maintenance
⑩ เปลี่ยน mysql_connection_string
⑪ Start oxmysql/Dependencies
⑫ ตรวจ Console
⑬ ทดสอบ Player Join
⑭ ทดสอบ Save
⑮ ตรวจ Database Error
⑯ ค่อยหยุดใช้ root Credential

59. อย่า Delete root Account เพราะ FiveM ไม่ใช้แล้ว

การเลิกใช้ root ใน FiveM Connection String ไม่ได้หมายความว่าต้องลบ MariaDB Administrative Account

Database Administrator ยังต้องมีวิธีดูแลระบบที่เหมาะสม

เป้าหมายคือ:

FiveM Application
≠
Database Administrator

60. User แยกต่อ Server ดีไหม

ถ้ามีหลาย FiveM Instances:

server_a
server_b
server_test

สามารถพิจารณาแยก:

fivem_a
fivem_b
fivem_test

และแยก Databases/Privileges ตามระบบ

ช่วยลดการที่ Credential ของ Server หนึ่งเข้าถึงข้อมูลอีก Server โดยไม่จำเป็น

61. Production กับ Test ควรใช้ User เดียวกันไหม

ควรหลีกเลี่ยงถ้าต้องการ Separation ที่ชัด

ตัวอย่าง:

Production
fivem_prod_user
→ fivem_prod.*

Test
fivem_test_user
→ fivem_test.*

ช่วยลดความเสี่ยงที่ Test Script เขียน Production Database ผิดตัว

62. Database Name ผิดแต่ User มีสิทธิ์กว้างจะเกิดอะไร

ถ้า User มี:

ALL PRIVILEGES ON *.*

แล้ว Connection String ชี้ผิด Database ก็อาจยังเข้าถึง Database อื่นได้

แต่ถ้า User ถูกจำกัด:

fivem_prod.*

ความผิดพลาดบางประเภทจะถูกจำกัดมากขึ้น

นี่เป็นอีกประโยชน์ของ Scope ที่แคบ

63. SHOW GRANTS ควรเก็บเป็น Documentation ไหม

มีประโยชน์

สามารถบันทึก:

Account
Host
Database Scope
Privileges
Purpose
Last Reviewed

โดยไม่เก็บ Password ลง Documentation

ทำให้เวลา Resource ใหม่ต้อง Permission เพิ่มจะเห็นได้ชัดว่ามีการเปลี่ยน Security Scope อะไร

64. Permission Review ควรทำเมื่อไร

อย่างน้อยเมื่อ:

เพิ่ม Framework
เพิ่ม Resource ใหญ่
เปิด Auto Migration
ย้าย Database
เปลี่ยน Production User
พบ Security Incident

รวมถึงหลังเลิกใช้ Resource ที่เคยต้อง Privilege สูง

65. Checklist FiveM Database User

ก่อน Production ตรวจ:

FiveM ไม่ใช้ root ถ้าไม่จำเป็น
มี Dedicated Database User
Password แข็งแรง
Password ไม่ซ้ำ
Host Scope ถูกต้อง
Database Scope ถูกต้อง
ไม่ใช้ *.* ถ้าไม่จำเป็น
ตรวจ SHOW GRANTS
มีเฉพาะ Runtime Privileges ที่จำเป็น
ตรวจ SELECT
ตรวจ INSERT
ตรวจ UPDATE
ตรวจ DELETE
ตรวจว่าต้อง CREATE หรือไม่
ตรวจว่าต้อง ALTER หรือไม่
ตรวจว่าต้อง DROP หรือไม่
ไม่มี GRANT OPTION หากไม่จำเป็น
ไม่มี CREATE USER หากไม่จำเป็น
Connection String ใช้ User ใหม่
Connection String ใช้ set
ไม่เก็บ Password ใน client.lua
ไม่โพสต์ Connection String
ไม่ Commit Secret สู่ Public Repository
Remote Host ถูกจำกัด
Firewall จำกัด Source
Production/Test แยก Credentials
Backup Config ก่อนเปลี่ยน
ทดสอบ Login ก่อน Production
ทดสอบ Player Join
ทดสอบ Character Load
ทดสอบ Save
ทดสอบ Resource Migration
ตรวจ Access Denied Logs
ถอน Privileges ที่ไม่จำเป็น
Review Permissions เมื่อ Stack เปลี่ยน

FiveM Database ใช้ root ดีไหม

ใช้ได้ในบาง Development/Administrative Context แต่ Production Application ควรพิจารณา Dedicated User ที่มี Privileges จำกัด

MariaDB Security Guidance แนะนำไม่ให้ใช้ root สำหรับ Routine Application Operations และให้ใช้ Dedicated Users ตามหลัก Least Privilege.

FiveM oxmysql ต้องมี Permission อะไร

ไม่มีชุดเดียวสำหรับทุก Server

Resource Stack ที่ใช้ CRUD อย่างเดียวอาจต้อง:

SELECT
INSERT
UPDATE
DELETE

ขณะที่ Resource ที่ Auto Migration อาจต้อง:

CREATE
ALTER
INDEX

เพิ่ม

ให้ตรวจ SQL/Documentation ของ Resources จริงก่อน Grant

FiveM สร้าง MariaDB User ยังไง

ตัวอย่าง:

CREATE USER
    'fivem_app'@'localhost'
IDENTIFIED BY
    'STRONG_PASSWORD';

MariaDB ใช้ CREATE USER เพื่อสร้าง Account ใหม่ โดย Account เริ่มต้นไม่ได้รับ Application Privileges จนกว่าจะ Grant เพิ่ม.

FiveM GRANT Permission ยังไง

ตัวอย่าง:

GRANT
    SELECT,
    INSERT,
    UPDATE,
    DELETE
ON
    `fivem`.*
TO
    'fivem_app'@'localhost';

MariaDB ใช้ GRANT สำหรับกำหนด Privileges ให้ Accounts.

FiveM ดู Database Permission ยังไง

ใช้:

SHOW GRANTS
FOR
    'fivem_app'@'localhost';

SHOW GRANTS แสดง Privileges ที่ Account ได้รับ.

FiveM ถอน Permission ยังไง

ใช้:

REVOKE ALTER
ON
    `fivem`.*
FROM
    'fivem_app'@'localhost';

MariaDB รองรับ REVOKE สำหรับถอน Privileges.

FiveM Access Denied หลังสร้าง User ใหม่

ตรวจ:

User
↓
Host
↓
Password
↓
GRANT
↓
Database Scope

เพราะ MariaDB Account ใช้คู่ User/Host เป็น Identity.

FiveM Database อยู่คนละเครื่องควรใช้ '%' ไหม

ไม่จำเป็นถ้ารู้ Host/IP ของ FXServer

การระบุ Source Host ให้แคบกว่ามักสอดคล้องกับ Least Privilege มากกว่าเปิดให้ทุก Host โดยไม่มี Requirement.

FiveM Database User ต้องมี DROP ไหม

ไม่เสมอไป

ถ้า Resources ไม่ Drop Database Objects ก็ไม่มีเหตุผลต้องให้ DROP แก่ Runtime User

ตรวจ Migration Requirements จริงก่อน

FiveM Auto Migration ต้อง ALTER ไหม

ขึ้นกับ Resource

หาก Resource ใช้ SQL:

ALTER TABLE

ตอน Start/Upgrade ก็ต้องมี Permission ที่รองรับ Operation นั้น หรือ Run Migration ด้วย User/Admin Workflow แยก

FiveM ใช้ User แยกสำหรับ Migration ได้ไหม

ได้ และเป็น Architecture ที่ดีสำหรับระบบที่ต้องการ Runtime Least Privilege

เช่น:

migration_admin
→ CREATE ALTER INDEX

fivem_app
→ SELECT INSERT UPDATE DELETE

แล้ว Runtime Connection ใช้ fivem_app

FiveM เปลี่ยน mysql_connection_string เป็น User ใหม่ยังไง

ตัวอย่าง:

set mysql_connection_string "mysql://fivem_app:PASSWORD@127.0.0.1:3306/fivem"

oxmysql ระบุให้ตั้ง Connection String ก่อน Start Resources และใช้ set กับค่านี้.

FAQ FiveM Database User และ Permissions

FiveM Database User คืออะไร

คือ MariaDB/MySQL Account ที่ oxmysql ใช้ Authenticate เพื่อให้ Resources เข้าถึง Database

FiveM ควรใช้ root ไหม

Production ควรพิจารณา Dedicated User แทน เพราะ MariaDB แนะนำไม่ให้ใช้ root สำหรับ Routine Application Operations.

CREATE USER ใช้ทำอะไร

ใช้สร้าง MariaDB Account ใหม่.

GRANT ใช้ทำอะไร

ใช้ให้ Privileges หรือ Roles แก่ Account.

SHOW GRANTS ใช้ทำอะไร

ใช้ดู Privileges ที่ User หรือ Role ได้รับ.

REVOKE ใช้ทำอะไร

ใช้ถอน Privileges จาก Account.

FiveM ต้องใช้ ALL PRIVILEGES ไหม

ไม่จำเป็นทุก Server ให้ Grant เท่าที่ Resources ต้องใช้จริง

FiveM ต้องใช้ CREATE USER Permission ไหม

Gameplay Resource ทั่วไปไม่จำเป็นต้องสร้าง MariaDB Accounts จึงไม่ควรให้โดยไม่มี Requirement

FiveM Runtime User ต้องใช้ ALTER ไหม

เฉพาะกรณี Resources ต้องแก้ Schema อัตโนมัติ หาก Migration ทำแยกโดย Administrator Runtime User อาจไม่ต้องมี ALTER

`'user'@'localhost'` กับ `'user'@'%'` ต่างกันไหม

ต่างกัน เพราะ MariaDB Account Identity รวม Host ไว้ด้วย.

Database User จำกัดเฉพาะ FiveM Database ได้ไหม

ได้ MariaDB รองรับ Database-level Privileges เช่น Scope fivem.*.

เปลี่ยนจาก root แล้ว oxmysql ใช้ได้ไหม

ได้ เพียง User ใหม่มี Authentication และ Privileges เพียงพอกับ Resource Stack แล้วตั้ง mysql_connection_string ให้ใช้ Account ใหม่.

ประเด็นสำคัญ

FiveM Database Security ไม่ควรจบแค่:

Database ต่อได้
=
เสร็จ

Architecture ที่เหมาะกว่าคือ:

FXServer
↓
oxmysql
↓
Dedicated FiveM User
↓
เฉพาะ fivem Database
↓
เฉพาะ Privileges ที่จำเป็น

MariaDB แนะนำ Least Privilege และ Dedicated Application Users แทนการใช้ root สำหรับ Routine Operations ขณะที่ CREATE USER, GRANT, REVOKE และ SHOW GRANTS เป็นเครื่องมือหลักสำหรับจัดการ Accounts และ Permissions.

สำหรับ Server ที่ Gameplay Runtime ต้องเพียง CRUD สามารถเริ่มวิเคราะห์จาก:

SELECT
INSERT
UPDATE
DELETE

แล้วเพิ่ม:

CREATE
ALTER
INDEX

เฉพาะเมื่อ Resource/Migration ต้องใช้จริง อย่าให้ ALL PRIVILEGES ON *.* เพียงเพราะ Setup ง่ายกว่า เพราะนั่นขยายขอบเขตสิทธิ์ของ Credential ที่ FiveM ถืออยู่มากเกินความจำเป็น

หาก Resource ต้อง Auto Migration สามารถพิจารณาแยก Migration/Admin User ออกจาก Runtime FiveM User แล้วถอน Schema-changing Privileges หลัง Deployment เพื่อให้ Runtime Account มีสิทธิ์แคบลง

สำหรับผู้อ่าน comsiam ให้จำสูตร “User แยก → Host จำกัด → Database จำกัด → Permission เท่าที่ใช้” และ comsiam แนะนำให้ใช้ SHOW GRANTS ตรวจสิทธิ์จริงทุกครั้งหลังเปลี่ยน Database User เพราะการสร้าง Dedicated User มีประโยชน์ก็ต่อเมื่อ Privileges ของ User นั้นถูกจำกัดอย่างถูกต้องจริง