'truncate' can fail because of fs.protected_regular

[swampdawg]

foo@sdu:/wrk/TT$ mkdir STICKY
foo@sdu:/wrk/TT$ sudo mount -t tmpfs -o mode=01777,size=1M tmpfs STICKY
foo@sdu:/wrk/TT$ ls -lad STICKY/
drwxrwxrwt 2 root root 60 Jun 23 07:47 STICKY/

foo@sdu:/wrk/TT$ df -hP | grep STICKY
tmpfs                          1.0M     0  1.0M   0% /wrk/TT/STICKY

foo@sdu:/wrk/TT$ touch STICKY/z
foo@sdu:/wrk/TT$ sudo truncate --size +1 STICKY/z #BAD
truncate: cannot open 'STICKY/z' for writing: Permission denied

foo@sdu:/wrk/TT$ truncate --size +1 STICKY/z #OKI

foo@sdu:/wrk/TT$ sudo chown root STICKY/z
foo@sdu:/wrk/TT$ sudo truncate --size +1 STICKY/z #OKI

foo@sdu:/wrk/TT$ sudo umount STICKY

https://unix.stackexchange.com/questions/691441/root-cannot-write-to-file-that-is-owned-by-regular-user

Probably not worth fixing because.. a) 'sysctl -w fs.protected_regular=0' as a transient fix is a huge security hole. b) 'chown root z' is nearly as bad. ..but.. truncate: cannot open "image_file" for writing: Permission denied ..probably needs to go in the FAQ because.. $ sudo sdm --extend "$IMG" --xmb 2048 ..will fail out of the box for a new user.

[gitbls]

Thanks for pointing this out. Nobody has had an issue with this in the past, so I agree that it's Probably not worth fixing.

But you also said:

$ sudo sdm --extend "$IMG" --xmb 2048 ..will fail out of the box for a new user.

Here is a "right out of the box" use that works just fine.

pw/ssdy/work/scratch/a$ sudo unxz -T 4 2024-03-15-raspios-bookworm-arm64-lite.img.xz 
pw/ssdy/work/scratch/a$ l
total 1695064
drwxr-xr-x 2 root root       4096 Jun 23 06:44 .
drwxr-xr-x 3 root root       4096 Jun 23 06:44 ..
-rwxr--r-- 1 root root 2768240640 Jun 23 06:43 2024-03-15-raspios-bookworm-arm64-lite.img
pw/ssdy/work/scratch/a$ sudo sdm --extend --xmb 2048 2024-03-15-raspios-bookworm-arm64-lite.img 
* Extend IMG by 2048MB (2.1GB, 2.0GiB)...
* Resize partition 2 of '2024-03-15-raspios-bookworm-arm64-lite.img' to 4375MB
* Remount IMG to resize the file system
* Mount IMG '2024-03-15-raspios-bookworm-arm64-lite.img'
mount: /dev/loop0 mounted on /mnt/sdm.
mount: /dev/loop1 mounted on /mnt/sdm/boot/firmware.
* Resize the file system
% (Ignore 'on-line resizing required' message)
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/loop0 is mounted on /mnt/sdm; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/loop0 is now 1068032 (4k) blocks long.

umount: /mnt/sdm/boot/firmware unmounted
umount: /mnt/sdm unmounted
pw/ssdy/work/scratch/a$

Perhaps you've modified something on your system to cause it to fail?

[swampdawg]

I didn't intend to imply "sdm --extend" fails in any other case except the one I highlighted. My bad ;-)

I can imagine someone using /tmp/ and having the issue I described (it doesn't have to be a tmpfs). The important thing is this 'truncate' feature is now known: it lead me a merry dance tracking it down.

[gitbls]

Won't fix. Closing.