თამაშის სერვერის ფაილების უფლებები და მფლობელობა

თამაშის სერვერი ერთი ჩვეულებრივი მომხმარებლის სახელით მუშაობს და მხოლოდ იმ ფაილების წაკითხვა, ჩაწერა ან გაშვება შეუძლია, რომლებზეც Linux-ის უფლებები ამ მომხმარებელს ამის ნებას აძლევს. თამაშის სერვერზე თითქმის ყოველი "Permission denied" სამიდან ერთ-ერთი მიზეზით ჩნდება: ფაილი, რომელიც სხვა მომხმარებელმა შექმნა (ჩვეულებრივ root-მა, მანქანაზე, რომელსაც თავად მართავ), სკრიპტი ან ბინარი, რომელსაც ატვირთვის შემდეგ executable bit დაეკარგა, ან ფაილი, რომელიც ვიღაცამ განზრახ read-only გახადა და დაავიწყდა. პანელზე მფლობელობის მხარეს ძირითადად შენ მაგივრად აგვარებენ - სერვერის საქაღალდეში ყველაფერი იმავე მომხმარებელს ეკუთვნის, რომლის სახელითაც სერვერი მუშაობს - ამიტომ დარჩენილი პრობლემები რეჟიმებია და უფლებების მეორე, ცალკე ფენა: შენი გუნდიდან ვის რომელ ფაილზე აძლევს პანელი შეხების უფლებას.

ეს პოსტი ორივე ფენას განიხილავს: რას ნიშნავს ასოები ls -l-ში, როგორ გაასწორო მფლობელობა და რეჟიმები, როდის არის კონფიგის read-only-ად გადაქცევა კარგი იდეა, რა შეცდომებს იწვევს თითოეული შეცდომა და როგორ მისცე მოდერატორს ფაილებზე წვდომა ისე, რომ ყველაფრის გასაღებები არ გადასცე.

უფლებების ორი ფენა#

სასარგებლოა მათი ერთმანეთისგან გამიჯვნა, რადგან ისინი სხვადასხვანაირად ფუჭდება.

1. Linux-ის ფაილების უფლებები წყვეტს, რისი გაკეთება შეუძლია თამაშის პროცესს ფაილთან. თუ ისინი არასწორია, თამაში ვარდება - ვერ ინახავს, ვერ ტვირთავს plugin-ს, ვერ ირთვება.
2. პანელის უფლებები წყვეტს, რისი გაკეთება შეუძლია ადამიანს პანელის ფაილების მენეჯერითა და SFTP-ით. თუ ისინი არასწორია, ადამიანი იბლოკება - ან, უარესი, არ იბლოკება მაშინ, როცა უნდა დაიბლოკოს.

ფაილი შეიძლება თამაშისთვის სრულიად წაკითხვადი იყოს და მოდერატორისგან სრულიად დამალული, ან მოდერატორისთვის რედაქტირებადი და თამაშისთვის წაუკითხავი. როცა რამე უარყოფილია, პირველი კითხვაა, რომელმა ფენამ თქვა უარი: შეცდომა თამაშის კონსოლში პირველი ფენაა, შეცდომა ფაილების მენეჯერში ან SFTP კლიენტში ჩვეულებრივ მეორეა.

Linux-ის უფლებების წაკითხვა#

ყოველ ფაილსა და საქაღალდეს აქვს მფლობელი, ჯგუფი და რეჟიმი. ls -l სამივეს აჩვენებს:

-rw-r--r-- 1 steam steam   1843 Oct  6 21:14 server.properties-rwxr-xr-x 1 steam steam    412 Oct  6 21:10 start.shdrwxr-xr-x 5 steam steam   4096 Oct  6 21:20 world-rw------- 1 root  root     96  Oct  6 20:55 token.txt

პირველი ათი სიმბოლო ტიპი და რეჟიმია. პირველი სიმბოლო არის - ფაილისთვის ან d დირექტორიისთვის. შემდეგი ცხრა სამ-სამად დაყოფილი სამი ჯგუფია: რისი გაკეთება შეუძლია მფლობელს, რისი შეუძლიათ ჯგუფის წევრებს და რისი შეუძლია ყველა დანარჩენს. თითოეულ ჯგუფში r წაკითხვაა, w ჩაწერა, x კი გაშვება.

დირექტორიებისთვის ასოები ოდნავ სხვა რამეს ნიშნავს, და ეს ხალხს აბნევს:

დირექტორიაში x-ის გარეშე ვერ შეხვალ, მაშინაც კი, თუ შიგნით ყველა ფაილი წაკითხვადია. დირექტორია w-ის გარეშე შიგნით ფაილის წაშლას ხელს უშლის, მაშინაც კი, თუ თავად ფაილი ჩაწერადია. თამაშებს, რომლებიც save-ს ახალი ფაილის შექმნით და მისი ძველზე გადარქმევით წერენ, w დირექტორიაზე სჭირდებათ და არა მხოლოდ save-ზე.

რეჟიმები ხშირად სამი რვაობითი ციფრით იწერება, თითო ჯგუფზე, სადაც წაკითხვა 4-ს ამატებს, ჩაწერა 2-ს და გაშვება 1-ს:

ახალი ფაილები რეჟიმს შემქმნელი პროცესის umask-იდან იღებს, ჩვეულებრივ 022-დან, რაც ფაილებისთვის 644-ს იძლევა და დირექტორიებისთვის 755-ს.

მფლობელობა: root-ის ხაფანგი#

მანქანაზე, რომელსაც თავად მართავ - VDS, სახლის სერვერი - უფლებების ყველაზე გავრცელებული პრობლემაა სერვერი, რომელიც არაპრივილეგირებული მომხმარებლის სახელით მუშაობს (ვთქვათ steam), და საქაღალდე, სავსე root-ის შექმნილი ფაილებით. ეს ასე ხდება: თამაშს steam-ის სახელით აყენებ, შემდეგ ერთ საღამოს განახლებას უშვებ ან mod-ს ხსნი root-ის სახელით sudo-თი. ეს ახალი ფაილები root-ს ეკუთვნის, რეჟიმით 644, და steam-ს მათი წაკითხვა შეუძლია, მაგრამ შეცვლა არა. სერვერი ირთვება, მუშაობს და ვარდება პირველივე მცდელობისას, როცა ცდილობს შეინახოს, კონფიგი განაახლოს ან mod-ის მონაცემების ფაილი გადაწეროს.

გამოსავალია ხე სერვისის მომხმარებელს დაუბრუნო და შემდეგ შეწყვიტო მასში რამის root-ით გაშვება:

# give the whole server folder back to the user it runs as$ sudo chown -R steam:steam /srv/valheim# run updates and edits as that user from now on$ sudo -u steam /home/steam/steamcmd/steamcmd.sh +runscript update.txt

თავად თამაშის root-ით გაშვება "უფლებების პრობლემების თავიდან ასაცილებლად" არასწორი გამოსავალია. მოწყვლადობის მქონე plugin-ს ან მავნე mod-ს მაშინ ერთი საქაღალდის ნაცვლად მთელ მანქანაზე სრული კონტროლი აქვს. რამდენიმე თამაშის სერვერი ერთ VDS-ზე აღწერს, როგორ გაუშვა თითოეული სერვერი საკუთარი მომხმარებლით, რაც ასევე ხელს უშლის, რომ ერთი სერვერის ფაილები მეორიდან იყოს მისაწვდომი.

მფლობელობა პანელზე#

Pterodactyl-ზე დაფუძნებულ პანელზე მთელი ეს კატეგორია ძირითადად ქრება. daemon ყველა სერვერის კონტეინერს ერთი არაპრივილეგირებული სისტემური მომხმარებლით უშვებს, და სერვერის საქაღალდე - ყველაფრის ჩათვლით, რასაც ფაილების მენეჯერით ან SFTP-ით ატვირთავ - ამ მომხმარებელს ეკუთვნის. პანელით ვერაფრით შექმნი root-ის კუთვნილ ფაილს შენი სერვერის საქაღალდეში, ამიტომ root-ის ხაფანგი არ ხდება.

მფლობელობის შეცვლაც არ შეგიძლია. chown-ს root სჭირდება, კონტეინერის შიგნით root არ არის, და SFTP კლიენტის "change owner" ოფცია Operation not permitted-ით ჩავარდება. ეს ჩაფიქრებულია: კონტეინერის იზოლაცია ამაზეა დამოკიდებული. თუ სიაში მფლობელობა არასწორად გამოიყურება, ჩვეულებრივ ეს SFTP კლიენტია, რომელიც აჩვენებს მომხმარებლის რიცხვით id-ს, რომლისთვისაც სახელი არ აქვს, და არა რეალური პრობლემა. როგორ ერგება ერთმანეთს კონტეინერები და daemon, ახსნილია სტატიაში Pterodactyl პანელის ახსნა.

რისი შეცდომით დაყენებაც პანელზე მაინც შეგიძლია, რეჟიმია.

executable bit#

shell სკრიპტს ან native ბინარს გასაშვებად x სჭირდება. როცა ის აკლია, შეცდომა პირდაპირია:

/home/container/start.sh: Permission deniedbash: ./RustDedicated: Permission denied

ჩვეულებრივი მიზეზები:

• ფაილი ბრაუზერით აიტვირთა. HTTP ატვირთვები შიგთავსს გადაიტანს და არა უფლებებს, ამიტომ ყოველი ატვირთული ფაილი 644-ით ჩადის.
• ის Windows-ზე შექმნილი zip-იდან მოვიდა. Windows-ს executable bit არ აქვს, ამიტომ იქ შექმნილი zip ფაილები მას არ ინახავს. Linux-ზე შექმნილი .tar.gz რეჟიმებს ინარჩუნებს; Windows-ის zip - არა.
• ის დაარედაქტირა და შეინახა ხელსაწყომ, რომელმაც ის თავიდან დაწერა, ადგილზე რედაქტირების ნაცვლად.

გამოსავალია chmod +x ფაილზე, ან რეჟიმის 755-ზე დაყენება. shell-ით ეს არის chmod +x start.sh. პანელზე გამოიყენე უფლებების ოფცია ფაილის მენიუში ფაილების მენეჯერში, სადაც შენი პანელი ამას გთავაზობს, ან Properties დიალოგი SFTP კლიენტში, როგორიცაა WinSCP ან FileZilla, რომელსაც რეჟიმის პირდაპირ დაყენება შეუძლია. SFTP და ფაილების მენეჯერი კლიენტებს განიხილავს.

მსგავსი შეცდომა უფლებების პრობლემას ჰგავს, მაგრამ არ არის:

/bin/sh^M: bad interpreter: No such file or directory

^M Windows-ის ხაზის დასასრულია. სკრიპტი CRLF ხაზის დასასრულებით შეინახა, და Linux კარეტის დაბრუნებას ინტერპრეტატორის სახელის ნაწილად კითხულობს. გადაიყვანე ის LF ხაზის დასასრულებზე შენს რედაქტორში (უმეტესობას ფანჯრის ბოლოში აქვს პარამეტრი) ან dos2unix-ით შენს მანქანაზე. რეჟიმის ვერანაირი ცვლილება ამას ვერ გაასწორებს.

read-only კონფიგები: როცა თამაში შენს ცვლილებებს აუქმებს#

თამაშის სერვერის კონფიგებზე ყველაზე გავრცელებული საჩივარი "Permission denied" კი არ არის, არამედ პირიქით: "პარამეტრი შევცვალე და თამაშმა უკან დააბრუნა." თითქმის ყოველთვის თამაშმა ფაილი მეხსიერებაში არსებული ასლიდან გადაწერა.

რამდენიმე თამაში ამას აკეთებს:

• Minecraft ჩართვისას server.properties-ს გადაწერს, ამატებს ნებისმიერ დაკარგულ გასაღებს ნაგულისხმევი მნიშვნელობებით და შენს კომენტარებს შლის. დაარედაქტირე ის გაჩერებული სერვერით და ჩანაწერები იმის შესახებ, რატომ არის მნიშვნელობა დაყენებული, სხვაგან შეინახე.
• Project Zomboid სერვერის .ini-ს ჩართვისას და თამაშში პარამეტრების შეცვლისას გადაწერს.
• Unreal Engine-ის თამაშები ხშირად თავიანთ Saved/Config ფაილებს გათიშვისას წერს, ამიტომ სერვერის მუშაობისას გაკეთებული ცვლილება ჩანაცვლდება იმით, რაც მეხსიერებაში იყო გაჩერების მომენტში.

სწორი გამოსავალი ყველა შემთხვევაში არის გააჩერე სერვერი, დაარედაქტირე, შემდეგ ჩართე. მოსაწყენია და ყოველთვის მუშაობს.

ფაილის read-only-ად გადაქცევა chmod 444-ით მეორე ვარიანტია, და ეს ხრიკია, რომლის შეზღუდვების ცოდნაც ღირს. ის ნამდვილად უშლის თამაშს ფაილის გადაწერას. მაგრამ ზოგი თამაში შეცდომას წერს ლოგში ყოველ ჯერზე, როცა მის შენახვას ცდილობს, ზოგი უარს ამბობს ჩართვაზე, როცა კონფიგის ჩაწერა არ შეუძლია, შენ კი ექვს თვეში დაგავიწყდება, რომ ის read-only-ია, დაარედაქტირებ და გაგიკვირდება, რატომ ვერ ინახავს რედაქტორი. SteamCMD-ის validate-იც ვერ დაგეხმარება, რადგან ის მხოლოდ თამაშთან ერთად მოსულ ფაილებს აღადგენს და არა მის მიერ გენერირებულს. თუ ამ ხრიკს იყენებ, ჩაწერე ეს თავად ფაილში (# read-only on purpose, see admin notes) და გამოიყენე მხოლოდ ფაილისთვის, რომლის ჩაუწერადობასაც თამაში, როგორც ცნობილია, იტანს.

შეცდომები და რას ნიშნავს ისინი#

Read-only file system ცალკე შენიშვნას იმსახურებს. ის რომელიმე ერთი ფაილის რეჟიმს არ ეხება: ოპერაციულმა სისტემამ მთელი ტომი read-only-ად მიამაგრა, ხშირად დისკის შეცდომის აღმოჩენის შემდეგ. სერვერის შიგნიდან ამას ვერ გაასწორებ, და ის დაუყოვნებლივ შენს ჰოსტს უნდა გადაეცეს ticket-ად.

პანელის უფლებები: ვის რომელ ფაილზე შეუძლია შეხება#

მეორე ფენა მნიშვნელოვანი ხდება მაშინვე, როგორც კი სერვერს ერთზე მეტი ადამიანი მართავს. Pterodactyl-ის სტილის პანელი მფლობელს საშუალებას აძლევს დაამატოს subuser-ები და თითოეულს უფლებების ნაკრები მისცეს, ფაილებთან დაკავშირებული უფლებები კი ჩვეულებრივ წვრილად არის დაყოფილი - upstream Pterodactyl-ში მათ შორისაა ცალკე უფლებები ფაილების წაკითხვაზე, ფაილების შიგთავსის წაკითხვაზე, შექმნაზე, განახლებაზე, წაშლაზე, დაარქივებასა და SFTP-ის გამოყენებაზე. RE:NODE ამას ავითარებს როლებით, გუნდებითა და grant-ებით: როლი უფლებებს ინახავს, გუნდი ადამიანებს, grant კი გუნდს სერვერთან აკავშირებს, დროში შეზღუდული წვდომით და აქტივობის ლოგით თითო სერვერზე.

როგორ ესადაგება ეს რეალურ გუნდს:

ორი რამის სწორად გაკეთება ღირს. პირველი, ფაილებზე წვდომა სრულ წვდომასთან ახლოსაა: ნებისმიერს, ვისაც ფაილების რედაქტირება შეუძლია, შეუძლია ადმინების სიის შეცვლა, plugin-ის დაყენება ან კონფიგში token-ის წაკითხვა. მიანიჭე ის ისეთივე სიფრთხილით, როგორითაც კონსოლზე წვდომას მიანიჭებდი. მეორე, SFTP წვდომა ცალკე უფლებაა, რადგან ის დანარჩენების გამოყენების ყველაზე ძლიერი გზაა - მთელი საქაღალდე წამებში შეიძლება ჩამოიტვირთოს ან ჩანაცვლდეს. subuser-ები და მინიმალური უფლებები როლების დაპროექტებას განიხილავს, ხოლო თამაშის სერვერის ადმინის ანგარიშის უსაფრთხოება - მათ უკან მდგომ ანგარიშებს.

ფაილები, რომლებიც საერთოდ არ უნდა იყოს წაკითხვადი#

თამაშის სერვერზე ზოგი ფაილი საიდუმლოა: Steam-ის თამაშის სერვერის token გაშვების ხაზში ან კონფიგში, FiveM-ის ლიცენზიის გასაღები server.cfg-ში, მონაცემთა ბაზის პაროლი plugin-ის კონფიგში, RCON-ის პაროლი. მანქანაზე, რომელსაც თავად მართავ, მიეცი მათ რეჟიმი 600, რომ მხოლოდ სერვისის მომხმარებელს შეეძლოს მათი წაკითხვა. პანელზე მნიშვნელოვანი კონტროლი მეორე ფენაა: ვისაც საერთოდ აქვს ფაილების წაკითხვის წვდომა. ისიც გახსოვდეს, რომ საიდუმლოებები ხვდება ადგილებში, სადაც შენ არ ჩაგიდია - ლოგებში გამეორებული გაშვების ხაზები, backup-ები, რომლებიც კონფიგებს შეიცავს, Discord-ში გაზიარებული ფაილების მენეჯერის screenshot-ები. გარემოს ცვლადები და საიდუმლოებები და RCON-ის უსაფრთხო გამოყენება განიხილავს ჩვევებს, რომლებიც მათ თავის ადგილზე ინახავს.

FAQ#

რატომ წერს ჩემი თამაშის სერვერი ჩართვისას Permission denied-ს?

ჩვეულებრივ გაშვების სკრიპტს ან ბინარს executable bit დაეკარგა, ხშირად ბრაუზერით ატვირთვის ან Windows-ის zip-იდან გახსნის შემდეგ. დააყენე ფაილის რეჟიმი 755-ზე შენს SFTP კლიენტში ან ფაილების მენეჯერში. თუ შეტყობინება ამის ნაცვლად მონაცემების ფაილს ასახელებს, სერვერის მომხმარებელს მასში ან მის საქაღალდეში ჩაწერა არ შეუძლია.

უბრალოდ chmod 777 გავუკეთო ყველაფერს?

არა. ეს ყოველ ფაილს სისტემის ყველა მომხმარებლისთვის ჩაწერადს ხდის, რაც გაზიარებულ მანქანაზე ან კომპრომეტირებული plugin-ის შემთხვევაში საჩუქარია. ის რეალურ პრობლემასაც იშვიათად ასწორებს, რომელიც ჩვეულებრივ მფლობელობაა ან ერთი დაკარგული executable bit.

რატომ ბრუნდება ჩემი კონფიგ ფაილი გამუდმებით საწყის მდგომარეობაში?

თამაშმა ის მეხსიერებიდან გადაწერა, ან ჩართვისას, ან გათიშვისას. გააჩერე სერვერი, გააკეთე ცვლილება და შემდეგ ისევ ჩართე. ფაილის read-only-ად გადაქცევა ზოგ თამაშში მუშაობს, ზოგში კი შეცდომებს იწვევს.

შემიძლია პანელის სერვერზე ფაილის მფლობელის შეცვლა?

არა, და არც გჭირდება. სერვერის საქაღალდეში ყველა ფაილი იმ მომხმარებელს ეკუთვნის, რომლის სახელითაც სერვერი მუშაობს, მფლობელობის შეცვლას კი root სჭირდება, რომელიც კონტეინერს არ აქვს.

შემიძლია ვინმეს მხოლოდ ერთ საქაღალდეზე მივცე წვდომა?

პანელების უმეტესობა ფაილების უფლებებს სერვერის დონეზე ანიჭებს და არა საქაღალდის. თუ ვინმე მხოლოდ ერთი plugin-ის კონფიგს უნდა შეეხოს, ყველაზე უსაფრთხო ვარიანტებია ცვლილების მის მაგივრად გაკეთება, ან საცდელი სერვერის მიცემა, სადაც სრული წვდომა ზიანს არ მოიტანს.