เหตุใดผู้ใช้ทั่วไปจึงไม่สามารถลบไดรฟ์ย่อย btrfs


12

การใช้ระบบไฟล์ btrfs ที่สร้างโดยผู้ใช้ที่มีการติดตั้งแบบวนรอบพร้อมการอนุญาตที่ถูกต้องผู้ใช้สามารถสร้าง bvfs subvolumes ได้อย่างอิสระ:

user@machine:~/btrfs/fs/snapshots$ /sbin/btrfs sub create newsubvol
Create subvolume './newsubvol'

อย่างไรก็ตามการพยายามลบผลลัพธ์ย่อยที่สร้างขึ้นใหม่มีข้อผิดพลาด:

user@machine:~/btrfs/fs/snapshots$ /sbin/btrfs sub del newsubvol
Delete subvolume '/home/user/btrfs/fs/snapshots/newsubvol'
ERROR: cannot delete '/home/user/btrfs/fs/snapshots/newsubvol'

แน่นอนว่าผู้ใช้รูทสามารถลบได้:

root@machine:/home/user/btrfs/fs/snapshots# /sbin/btrfs sub del newsubvol
Delete subvolume '/home/user/btrfs/fs/snapshots/newsubvol'

พฤติกรรมที่แตกต่างระหว่างการดำเนินการสร้างและลบนี้ดูแปลกไปหน่อย มีใครบ้างไหมที่ให้แสงนี้?

นี่คือลำดับของคำสั่งที่แน่นอน:

user@machine:~$ dd if=/dev/zero of=btrfs_disk bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 1.2345 s, 84.9 MB/s
user@machine:~$ mkdir mountpoint
user@machine:~$ /sbin/mkfs.btrfs btrfs_disk

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

SMALL VOLUME: forcing mixed metadata/data groups
Created a data/metadata chunk of size 8388608
fs created label (null) on btrfs_disk
    nodesize 4096 leafsize 4096 sectorsize 4096 size 100.00MB
Btrfs Btrfs v0.19
user@machine:~$ sudo mount btrfs_disk mountpoint/
user@machine:~$ cd mountpoint/
user@machine:~/mountpoint$ /sbin/btrfs sub create test
Create subvolume './test'
user@machine:~/mountpoint$ /sbin/btrfs sub delete test
Delete subvolume '/home/user/mountpoint/test'
ERROR: cannot delete '/home/user/mountpoint/test' - Operation not permitted

นี่คือการอนุญาต:

user@machine:~/mountpoint$ ls -la
total 4
drwxr-xr-x 1 user user    8 Set  4 09:30 .
drwx------ 1 user user 4486 Set  4 09:29 ..
drwx------ 1 user user    0 Set  4 09:38 test

และสายที่เกี่ยวข้องกับdf -T:

Filesystem              Type     1K-blocks      Used Available Use% Mounted on
/dev/loop0              btrfs       102400        32     98284   1% /home/user/mountpoint

Distro เป็น Debian Wheezy, 3.2.0-4-686-paekernel, v0.19btrfs-tools สถานการณ์ยังคงเกิดขึ้นกับ Ubuntu Saucy, 3.11.0-4-genericเคอร์เนล, v0.20-rc1เครื่องมือ btrfs


จากความเข้าใจของฉันระบบไฟล์ประเภทนี้ยังคงอยู่ในช่วงทดลองและยังไม่พร้อมใช้งาน
mdpc

คุณสามารถเพิ่มผลลัพธ์ของdf -Tและbtrfs version? เมื่อฉันลองแบบเดียวกันฉันได้รับข้อความแสดงข้อผิดพลาด "ข้อผิดพลาด: ไม่สามารถสร้างหัวข้อย่อย - การอนุญาตถูกปฏิเสธ"
bsd

@mdpc แม้ว่าจะเป็นจริง แต่ btrfs ก็อยู่ในช่วงหลายปีที่ผ่านมาและคาดว่าจะค่อนข้างเสถียรในขั้นตอนนี้ มันอาจจะมีประโยชน์ที่จะเข้าใจว่านี่เป็นจุดบกพร่องหรือ 'คุณสมบัติ' ณ จุดนี้
goncalopp

@downing ฉันได้เพิ่มลำดับคำสั่ง df และรุ่นที่ฉันใช้อย่างแน่นอน
goncalopp

เคอร์เนล 3.2 นั้นมีอายุมากกว่าหนึ่งปีครึ่งแล้ว หากคุณต้องการเล่นกับระบบไฟล์ทดลองคุณอาจต้องการเรียกใช้เคอร์เนลล่าสุด
psusi

คำตอบ:


14

นี่เป็นประสบการณ์การเรียนรู้สำหรับฉัน แต่ในที่สุดฉันก็ค้นพบมัน ฉันจะอธิบายกระบวนการของฉันที่นี่เพื่อให้ง่ายต่อการทราบวิธีการคิดสิ่งนี้ด้วยตัวคุณเอง (เอกสาร BTRFS ที่ฉันแน่ใจว่าคุณพบว่าค่อนข้างไม่สมบูรณ์ในขณะนี้)

ตอนแรกฉันคิดว่าการสร้าง subvolume นั้นioctlเป็นตัวจัดการที่ไม่ได้ทำการตรวจสอบความสามารถใด ๆ (ซึ่งอาจหรืออาจไม่ใช่ปัญหาด้านความปลอดภัยขึ้นอยู่กับว่ามีเหตุผลบางอย่างอยู่หรือไม่) ในขณะที่การลบมันเป็นการแก้ไข metadata โดยตรง (และผู้ใช้อาจต้องCAP_SYS_RAWIOทำงานอย่างถูกต้อง)

ในการตรวจสอบฉันได้เปิดbtrfs-utilsซอร์สโค้ดและนี่คือสิ่งที่ฉันพบ:

Create subvolume, cmds-receive.c Line 180:
         ret = ioctl(r->dest_dir_fd, BTRFS_IOC_SUBVOL_CREATE, &args_v1);

Delete subvolume, cmds-subvolume.c Line 259:
         res = ioctl(fd, BTRFS_IOC_SNAP_DESTROY, &args);

ดีที่ไม่เป็นประโยชน์พวกเขาทั้งสองของ ioctl (หมายเหตุด้านที่น่าสนใจ: "ภาพรวม" มักถูกใช้แทนกันในซอร์สโค้ดด้วย "subvolume" ด้วยเหตุผลบางอย่าง) fs/btrfs/ioctl.cดังนั้นผมจึงไปซอร์สโค้ดเคอร์เนลและพบรถขนทั้งใน

ในที่สุดฉันตามรอยกลับไปbtrfs_ioctl_snap_destroy()ที่บรรทัด 2116:

     if (!capable(CAP_SYS_ADMIN)){

โดยเฉพาะนี่คือการตรวจสอบว่าพวกเขาไม่มีความสามารถ แต่ถ้าพวกเขามีมันตรรกะจะข้ามไปที่การดำเนินการ เนื้อความของคำสั่ง if ตรวจสอบเพื่อดูว่าเป็นผู้ใช้ปกติที่เป็นเจ้าของ inode ของ subvolume หรือไม่และUSER_SUBVOL_RM_ALLOWEDตัวเลือก BTRFS เปิดใช้งานจะยังคงดำเนินการตัวจัดการต่อไป หากพวกเขาไม่มี ioctl handler ออกด้วยข้อผิดพลาด

ดังนั้นดูเหมือนว่าการทำลาย "snapshot" (aka "subvolume") โดยทั่วไปต้องการผู้ใช้ที่มีCAP_SYS_ADMIN(หรือUSER_SUBVOL_RM_ALLOWEDเพื่อเปิดใช้งานและผู้ใช้ "เป็นเจ้าของ" subvolume ที่กำหนด) เยี่ยมมากแล้วการสร้างภาพรวม / ปริมาณ

ตัวจัดการสำหรับ ioctl ดูเหมือนจะเป็นbtrfs_ioctl_snap_create()ตัวจัดการนี้ดูเหมือนจะไม่มีการโทรcapable()โดยตรงหรือโดยอ้อม เนื่องจากนั่นเป็นวิธีหลักในการเข้าถึงจึงทำให้ฉันได้รับสิ่งนี้หมายความว่าการสร้าง subvolume ประสบความสำเร็จเสมอ สิ่งนี้จะอธิบายในระดับการใช้งานว่าทำไมคุณถึงเห็นสิ่งที่คุณเห็น

ฉันไม่สามารถพูดได้ว่าเหตุใดจึงถือว่าเป็นสิ่งที่น่าพึงพอใจนอกกรณีการใช้งานหลักของ BTRFS ที่อยู่กับเซิร์ฟเวอร์ที่มีการ จำกัด การเข้าถึงของผู้ใช้ ไม่เพียงพอ แต่ฉันไม่เห็นรหัสใด ๆ เพื่อหยุดการดำเนินการ หากคุณไม่สามารถหาคำตอบว่าทำไม (และคุณสนใจ) คุณอาจต้องถามรายชื่อการส่งเมลเคอร์เนล

ข้อสรุป

งานวิจัยของฉันดูเหมือนจะบ่งบอกว่าทุกคนสามารถสร้างไดรฟ์ย่อยได้ แต่เพื่อที่จะลบไดรฟ์ย่อยคุณจำเป็นต้องมีCAP_SYS_ADMINหรือจำเป็นต้องเป็นจริงทั้งที่ผู้ใช้ที่โทรเป็นเจ้าของโหนดย่อยและUSER_SUBVOL_RM_ALLOWEDเปิดใช้งาน

การสร้างไดรฟ์ย่อยไม่เหมาะสมดังนั้นฉันอาจพลาดวิธีการทางอ้อมที่ถูกปฏิเสธเนื่องจากดูเหมือนจะเป็นวิธีที่ง่ายในการใช้ระบบ DoS

หมายเหตุ: ฉันไม่ได้อยู่ในสถานที่ที่ฉันสามารถตรวจสอบการทำงานนี้ แต่เมื่อฉันกลับถึงบ้านฉันสามารถตั้งค่าถ้าsetcapเวทมนตร์ทำงานตามที่ทำนายนี้


วิธีที่เหมาะสม (เกี่ยวกับข้อกังวลของคุณเกี่ยวกับ DoS) คือถ้าrmdirได้รับอนุญาตให้ทำใน subvolumes ที่ว่างเปล่า จากนั้นrm -rจะทำงานอย่างโปร่งใส น่าเสียดายที่รหัสนั้นยังไม่ได้รับการพัฒนา (ยัง) ดูเหมือนว่ามีคนลองสามครั้งในปี 2010 และเลิกใช้แล้ว :(. spinics.net/lists/linux-btrfs/msg06499.html
sourcejedi

5

การลบไดรฟ์ย่อยช่วยให้ใครบางคนที่จะเชื่อมโยงไฟล์ที่พวกเขาไม่ได้เป็นเจ้าของ ในความคิดของฉันไฟล์ที่ผู้ใช้ที่มีสิทธิพิเศษเขียนในสถานที่ที่เลือกโดยผู้ใช้ที่มีสิทธิพิเศษน้อยกว่านั้นเป็นเกมที่ยุติธรรม แต่ผู้ที่สนับสนุนการลบแบบ non-root อาจไม่รู้สึกมั่นใจเพียงพอเกี่ยวกับความหมายของความปลอดภัยเหล่านั้น เพื่อส่งพวกเขาเป็นตัวเลือกเมานท์ใหม่ ( mount -o user_subvol_rm_allowed)


1
น่าประหลาดใจในUNIX®คุณสามารถยกเลิกการเชื่อมโยงไฟล์ที่คุณไม่ได้เป็นเจ้าของได้อย่างง่ายดายคุณเพียงแค่ต้องมีสิทธิ์เขียนในไดเรกทอรี
poige

ฉันมีปัญหาเดียวกันกับ fedora 20 ฉันมี / home ใน subvolume ฉันใช้ root ของผู้ใช้ แต่อย่างไรก็ตามฉันไม่สามารถลบ / home ได้
c4f4t0r

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

-1

"ไม่สามารถลบ / home" (ซึ่งเป็น @home)

ทำไมคุณต้องการลบไดรฟ์ย่อยที่ / home / บัญชีของคุณอยู่เว้นแต่ว่าคุณได้สร้าง / home_snapshot_yymmdd snapshot เพื่อแทนที่ / home ด้วย?

ฉันยังใหม่กับการใช้ btrfs แต่นี่คือสิ่งที่ฉันค้นพบ: @ / และ @home (/ และ / home) ถูกสร้างโดย btrfs เมื่อติดตั้งบน HD ของคุณเป็นระบบไฟล์ นอกจากว่าคุณกำลังทำการกู้คืน / home จาก snapshot ก่อนหน้านี้เนื่องจากฉันเข้าใจแล้วคุณจะต้องตัดตัวเองให้คุกเข่า

อย่างไรก็ตามคุณสามารถติดตั้งอุปกรณ์ที่ / home เปิด AS ROOT โดยใช้เมานต์ / dev / sa / mnt / (หรืออุปกรณ์ใดที่เคยใช้ระบบ btrfs ของคุณที่เปิดอยู่) จากนั้น cd to / mnt / และออกคำสั่ง delete สำหรับ @บ้าน. จากนั้นคุณสามารถใช้คำสั่ง mv เพื่อย้าย @home_snapshot_yymmdd (หรือที่คุณเคยตั้งชื่อ) ไปที่ @home การย้ายอาจใช้เวลาเป็นชั่วโมงขึ้นอยู่กับขนาดของ @home จากนั้น CD กลับไปที่บัญชีของคุณและออก sudo umount / mnt / คุณไม่เคยออกจากระบบหรือปิดระบบของคุณจริงๆ นั่นคือความงามของ btrfs


ดูเหมือนว่าพวกเขาได้ทำไปแล้ว Btrfs ไม่ได้สร้าง @ และ @home เว้นแต่คุณจะบอกพวกเขาถึง (หรือ distro ของคุณเช่น Ubuntu ทำเพื่อคุณ)
Anthon
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.