ทำไมไม่มีตัวจัดการไฟล์ขออนุญาตที่สูงขึ้นหากจำเป็น? [ปิด]


14

ฉันเพิ่งตอบคำถามผู้เริ่มต้นเกี่ยวกับ "ไม่สามารถเขียน ....... ตรวจสอบสิทธิ์"

แน่นอนฉันรู้วิธีใช้ chown / chmod; ฉันกำลังทำงานกับบรรทัดคำสั่งอยู่แล้ว แต่ผู้บริโภคโดยเฉลี่ยไม่ได้

ดังนั้นฉันควรบอกอะไรกับคนที่ไม่มี GNU / Linux-experience

ทำงานเป็น root หรือไม่ ฉันรู้ว่าตัวอย่างเช่น Nemo มีฟังก์ชั่น "open as root" แต่ไม่ใช่! ฉันไม่คิดว่ามันเป็นความคิดที่ดีสำหรับผู้ใช้ทั่วไป มันอันตรายมาก จากนั้นผู้ใช้สร้างไฟล์ใน root-file-manager และสงสัยว่าทำไมเขาไม่สามารถลบหรือแก้ไขไฟล์นี้ และอื่น ๆ

บอกให้เขาเรียนรู้วิธีใช้ chown / chmod? และที่นี่เราเป็น - nerd-only-linux ที่ทุกอย่างซับซ้อนมาก นั่นคือวิธีที่เราทำสิ่งต่าง ๆ ; แต่มันไม่ใช่ตัวเลือกที่ดีสำหรับผู้บริโภคทั่วไป

ทำไมตัวจัดการไฟล์ถึงไม่ช่วย

ฉันเกลียดที่จะพูดแบบนี้ แต่ดูว่า Windows จัดการกับสิ่งนี้อย่างไร ค่าเริ่มต้นคือการอนุญาตของผู้ใช้ และถ้าตัวจัดการไฟล์ต้องการมากกว่านี้ - มันแค่ถามผู้ใช้

การดำเนินการนี้ไม่ยาก หากการดำเนินการล้มเหลวโดยมีข้อยกเว้นสิทธิ์ - ลองดำเนินการกับ gksudo

และใช่: ฉันไม่มีประสบการณ์จริง ๆ กับโอเพนซอร์ซทั้งหมด

คำถามของฉัน:

  1. มีเหตุผลใดบ้างที่ไม่ทำเช่นนี้
  2. มีใครบ้างไหมที่ทำอย่างนั้น?
  3. นี่เป็นสิ่งที่คุณรายงานว่าเป็นข้อบกพร่อง (Ubuntu หรือเช่น Gnome) หรือไม่
  4. นี่เป็นสิ่งที่ฉันสามารถลองใช้กับตัวเองได้หรือไม่

4
ทำไมคุณต้องการคัดลอกพฤติกรรมของ Windows ไปยังระบบ Linux พวกเขาเป็นเพียงสองระบบปฏิบัติการที่แตกต่างกันและแตกต่างกัน ใน Linux คุณทำงานในฐานะผู้ใช้ปกติและโดยปกติไม่ต้องการrootสิทธิ์ยกเว้นว่าคุณทำงานเป็นผู้ดูแลระบบ ในกรณีนี้คุณควรทำงานเป็นผู้ดูแลและแยกโลกทั้งสองออกจากกัน คุณสามารถติดตั้งซอฟแวร์ในไดเรกทอรีที่บ้านของคุณให้การตั้งค่าสภาพแวดล้อมของคุณเองใน.bashrc, .profileฯลฯ ...
โทมัส

2
ฉันต้องคิดถึงบางอย่าง แต่ทำไมคุณถึงคิดว่า"ฉันรู้ว่าตัวอย่างเช่น Nemo มีฟังก์ชั่น" open as root "แต่ไม่! ฉันไม่คิดว่ามันเป็นความคิดที่ดีสำหรับผู้ใช้ทั่วไป แต่ในเวลาเดียวกัน"ดูวิธีการที่ Windows จัดการนี้เริ่มต้นใช้งานได้รับอนุญาตและถ้าความต้องการจัดการไฟล์อื่น ๆ -.. ก็แค่ขอให้ผู้ใช้ " -a คิดที่ดี? Que?
Jacob Vlijm

5
หากต้องการปิดผู้ลงคะแนน: จริงจังหรือไม่ นี่เป็นคำถามที่ยอดเยี่ยมและมีคำตอบที่ดีมากอยู่แล้ว ด้วยอาจจะมาเพิ่มเติม หากมีเหตุผลทางเทคนิคใด ๆ ที่ไม่ใช้การปรับปรุงที่ชัดเจนนี้จะสามารถให้คำตอบได้
Andrea Lazzarotto

2
@Arronic ประเด็นคือไม่มีเครื่องมือ GUI ดังกล่าวสำหรับกรณีจำนวนมาก แม้แต่ macOS ยังมีตัวเลือก GUI เพิ่มเติมสำหรับการปรับแต่งไฟร์วอลล์เซิร์ฟเวอร์ SSH และอื่น ๆ ดังนั้นคำถามของ OP คือ: ทำไม
Andrea Lazzarotto

3
หาก Linux บนเดสก์ท็อปสำหรับผู้ที่ไม่มีความรู้ด้านเทคนิคกำลังจะเดินทางไปทุกที่ก็จำเป็นที่จะต้องลบความต้องการที่จะทำงานในตัวจัดการไฟล์ในฐานะที่เป็นรูทออกไป ฉันไม่สามารถนึกถึงสิ่งที่ผู้ใช้ทั่วไปควรทำในตัวจัดการไฟล์ในฐานะรูท (แน่นอนมีหลายสิ่งที่พวกเขาต้องทำในปัจจุบัน) จากนั้นปัญหานี้จะแก้ไขได้ค่อนข้างง่าย IMHO หากผู้ใช้กำลังสร้างไฟล์ที่เป็นเจ้าของรูทในโฮมไดเร็กตอรี่ของตัวเองมีบางอย่างผิดปกติอยู่แล้ว
Muzer

คำตอบ:


14
  1. มีเหตุผลใดบ้างที่ไม่ทำเช่นนี้

ไม่มีอะไรพิเศษ ฉันสามารถบอกเหตุผลที่ควรได้ แต่พวกเขาส่วนใหญ่เป็นการเก็งกำไร

  1. มีใครบ้างไหมที่ทำอย่างนั้น?

ไม่มาก มีnautilus-adminส่วนขยายที่จะช่วยให้คุณเปิดไดเรกทอรีในหน้าต่างใหม่ด้วยสิทธิ์ระดับรากแล้วคุณสามารถเปลี่ยนการอนุญาตไฟล์ / ไดเรกทอรีตามที่คุณต้องการจากคลิกขวาเมนู -> คุณสมบัติ -> สิทธิ์

  1. นี่เป็นสิ่งที่คุณรายงานว่าเป็นข้อบกพร่อง (Ubuntu หรือเช่น Gnome) หรือไม่

รายงานข้อผิดพลาด? ไม่ขอคุณสมบัติ? อาจเป็นไปได้ คุณสามารถส่งสิ่งนี้เป็นคำขอคุณลักษณะให้กับทีมงาน Nautilus (ผู้จัดการไฟล์) บนLaunchpadแต่ฉันสงสัยว่า 90% แน่นอนว่าพวกเขาจะชี้คุณในnautilus-adminส่วนขยายที่ฉันกล่าวถึงข้างต้น

sudo apt-get install nautilus-adminติดตั้งด้วย

  1. นี่เป็นสิ่งที่ฉันสามารถลองใช้กับตัวเองได้หรือไม่

ใช่ถ้าตัวจัดการไฟล์ของคุณอนุญาตให้เพิ่มสคริปต์เข้าไป ตัวจัดการไฟล์เริ่มต้นสำหรับ Ubuntu (Nautilus) อนุญาตให้เพิ่มสคริปต์ลงไปดังนั้นคุณสามารถทำสิ่งนี้:

#!/bin/bash
# adds read permissions for file for all users
zenity --password | sudo -S -p ""  chmod +r  "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS" || zenity --error --text "Command failed"

วางสิ่งนั้นลงใน ~/.local/share/nautilus/scriptsไฟล์ให้สามารถเรียกใช้chmodงานได้แล้วจากนั้นมันจะสามารถเข้าถึงได้ผ่านการคลิกขวาที่ไฟล์ แน่นอนว่าเป็นเพียงตัวอย่างเล็กน้อยเพื่อแสดงให้เห็นจุด หากคุณต้องการแอพเป่าเต็มรูปแบบที่ช่วยให้คุณสมบัติที่ซับซ้อนมากขึ้นเช่นการเลือกการอนุญาตที่จะแก้ไขซึ่งอาจต้องใช้คำสั่งพิเศษและอาจเป็นภาษาอย่าง Python ที่มีชุดเครื่องมือ GUI ที่ทรงพลังกว่า

แต่ไม่ใช่! ฉันไม่คิดว่ามันเป็นความคิดที่ดีสำหรับผู้ใช้ทั่วไป มันอันตรายมาก จากนั้นผู้ใช้สร้างไฟล์ใน root-file-manager และสงสัยว่าทำไมเขาไม่สามารถลบหรือแก้ไขไฟล์นี้ และอื่น ๆ

ดี ... มันไม่ใช่ปัญหาคอมพิวเตอร์ - เป็นปัญหาของผู้ใช้ เราไม่สามารถแก้ไขผู้ใช้ที่ไม่เต็มใจที่จะเรียนรู้วิธีการใช้งานคอมพิวเตอร์อย่างเหมาะสมและไม่รับผิดชอบต่อการกระทำของพวกเขา

ผู้ใช้ต้องตระหนักว่าการแยกความเป็นเจ้าของในไฟล์นั้นมีอยู่ด้วยเหตุผล คุณไม่สามารถมีอำนาจทั้งสองในการเปลี่ยนการอนุญาตในไฟล์และไม่คาดหวังความปลอดภัย


4
คำตอบที่ยอดเยี่ยม แต่ปัญหายังคงอยู่: GUI บน distros โดยค่าเริ่มต้นไม่อนุญาตให้ผู้ใช้ "sudo แบบกราฟิก" เมื่อจำเป็น ผู้ใช้ต้องปลดล็อกบัญชีรูทด้วยตนเอง (ไม่ดี) หรือต้องเปลี่ยนไปใช้บรรทัดคำสั่ง เช่นฉันเป็นนักพัฒนาฉันชอบ CLI ... แต่ฉันก็คิดถึงครอบครัวและเพื่อนของฉันที่ไม่ใช่ บางครั้งเมื่อพวกเขาใช้ลีนุกซ์พวกเขาจะขอความช่วยเหลือจากฉันและ 80% ของเวลานั้นเกี่ยวกับการทำบางสิ่งในฐานะผู้ใช้ที่มีสิทธิพิเศษ : /
Andrea Lazzarotto

ขอบคุณ; โดยเฉพาะอย่างยิ่งสคริปต์มีประโยชน์มาก มีการรายงานคำขอคุณสมบัติเช่นข้อบกพร่อง (โปรดทราบว่านี่คือคำขอคุณลักษณะ) ใช่ไหม
AnnoSiedler

@ AnnoSiedler พูดอย่างกว้างขวางว่าใช่; มันจะดีกว่าถ้าคุณใส่ "[การเพิ่มประสิทธิภาพ]" หรือ "[คุณสมบัติ]" ในชื่อเรื่องและเริ่มต้นด้วยเรื่องราวของผู้ใช้ที่ดีและไม่นำเสนอปัญหาของคุณเป็นข้อบกพร่อง (เช่น "ขั้นตอนในการ
ทบทวน

16
“ ก็…มันไม่ใช่ปัญหาคอมพิวเตอร์ - มันเป็นปัญหาของผู้ใช้ เราไม่สามารถแก้ไขผู้ใช้ที่ไม่เต็มใจที่จะเรียนรู้วิธีการใช้งานคอมพิวเตอร์อย่างเหมาะสมและไม่รับผิดชอบต่อการกระทำของพวกเขา” อ๊ะไม่ ผู้คนยกมือกันและตำหนิผู้ใช้นั่นเป็นสาเหตุที่ทำให้สิ่งต่าง ๆ เกิดความสับสนหรือขัดข้อง การออกแบบ UX เป็นสิ่งที่สำคัญจริง ๆ ที่ผู้ออกแบบโปรแกรมต้องใส่ใจคิดและทำงานในคำอื่น ๆ ต้องเป็นเจ้าของและรับผิดชอบ ไม่ใช่ความผิดของผู้ใช้ - เป็นข้อ จำกัด ทางเทคนิคหรือข้อกังวลด้านความปลอดภัยหรืออาจเป็น UX ที่ไม่ดีที่ต้องแก้ไข
KRyan
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.