8 ms·
Casually removing root files
- reptation 9y agoThis is only true for some filesystems. ext4 notably doesn't acknowledge -i attribute
- teilo 9y agoNot true. Immutable works just fine on ext4. https://pastebin.com/beuimxR8 https://pastebin.com/beuimxR8
- jwilk 9y agoIndeed. The list of all supported attributes is in the manual page: http://man7.org/linux/man-pages/man5/ext4.5.html#FILE_ATTRIBUTES http://man7.org/linux/man-pages/man5/ext4.5.html#FILE_ATTRIB...
- reptation 9y agoAh, you're right, I mis-remembered: """ The `c', 's', and `u' attributes are not honored by the ext2, ext3, and ext4 filesystems as implemented in the current mainline Linux kernels. """
- shabble 9y agoThat's pretty cute. `chattr +i' can be pretty handy for preventing misbehaving tools which must run as root from mangling your precious files. Also for messing with people on multi-user boxes :) As a tiny issue, in the 3rd snippet, '/home/user/shoe/little-rock' should be left-shoe, no?
- heywire 9y agoIt can also be helpful if you have a mountpoint that normally points at a remote machine (backup machine, etc), but that remote machine is unavailable for some reason. It keeps your backups from going into the mountpoint itself instead of the intended destination.
- dEnigma 9y ago> As a tiny issue, in the 3rd snippet, '/home/user/shoe/little-rock' should be left-shoe, no? Yes, that part probably doubled the time it took me to read the first part of the post, because I had to double-check everything.
- wolfgang42 9y ago> The only requirement is to have write permissions on the parent directory (and the execute flag on the parent directory). > The $HOME directory naturally fulfills both of these requirements from the user’s perspective. Note that there's nothing special about the user's home directory here, it just happens to normally have u+wx. It's entirely possible to have the user's home not owned by themselves; you might want to do this for example if you have a restricted user who you don't want messing around with their dotfiles.
- lossolo 9y agoI was using chattr +i as a quick workaround to the fact that Ubuntu overwrites Xorg.conf every time you restart it, which overwrote my nvidia GPU overclock settings. Setting +i made it immutable.
- gegenschall 9y agoYou should be using /etc/X11/xorg.conf.d/*.conf for that.
- lossolo 9y agoNo, this path will not work. If anything it should be /usr/share/X11/xorg.conf.d
- peterwwillis 9y agoIf you're using Slackware, or another sane distribution, /etc/X11/xorg.conf.d/ is where you put user-specific X configuration. Making the config immutable would prevent overwrite. Making local edits in any part of /usr/ is extremely frowned upon.
- gegenschall 9y agoApologies. I haven't been using Ubuntu in a while and did not know you had to modify stuff under /usr there. (Eww!)
- aleden 9y agoIf one must install grub to a partition (e.g. on a first-generation Mac Pro), one is advised on the ArchLinux Wiki to use chattr: Warning: GRUB strongly discourages installation to a partition boot sector or a partitionless disk as GRUB Legacy or Syslinux does. This setup is prone to breakage, especially during updates, and is not supported by the Arch developers. # chattr -i /boot/grub/i386-pc/core.img # grub-install --target=i386-pc --debug --force /dev/sdaX # chattr +i /boot/grub/i386-pc/core.img in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the /boot/grub/i386-pc/core.img file and the prefix directory /boot/grub. The sector locations of core.img may change whenever the file system in the partition is being altered (files copied, deleted etc.). The workaround for this is to set the immutable flag on /boot/grub/i386-pc/core.img (using chattr command as mentioned above) so that the sector locations of the core.img file in the disk is not altered. The immutable flag on /boot/grub/i386-pc/core.img needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of core.img without embedding any bootsector (mentioned above). https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks
- exikyut 9y agoThis is a very useful trick, and allows for the design of ridiculously simple bootloaders. If you +i vmlinux, IIRC you can fit a loader for it into 448 bytes.
- JimDabell 9y agoIsn't this just a roundabout way of saying that you can remove files from a directory you have write access to? What's the relevance here?
- etskinner 9y agoThe point seems to be that this isn't expected behavior in most people's minds, and that if someone truly wants to allow users to write to a directory, but not allow them to delete a file, that file must be flagged immutable. Just a quirky edge cases that people might not know about.
- jstanley 9y agoIt is expected behaviour if your mental model is accurate enough. My mental model is that a directory is just a special file that links to other files. Adding or deleting a file to a directory is just a case of writing to the "special file" to add or remove links to other files.
- yberreby 9y agoBut if the file you are removing is the only reference (i.e. hard link) to that inode, you're not just modifying the directory's contents; you're also removing data from the filesystem as a whole.
- glandium 9y agoNote that something else also happens to the inode when it's not the only reference: removing a file changes the "nlink" counter on the inode.
- paulddraper 9y agoRight. You are only affecting that directory listing. Any other hardlinks in any other directories are completely unaffected.
- cortesoft 9y ago
- alethiophile 9y agoMy use case for `chattr +i`: an rsync backup, on a cronjob, into an external drive mounted at a given point. Make the mountpoint directory `+i` so that the root-run rsync doesn't blindly fill up your root filesystem with the backup target, if it gets run while the external drive isn't mounted.
- switch007 9y agoAlso useful: "mountpoint" can tell you if a path is mounted. https://linux.die.net/man/1/mountpoint https://linux.die.net/man/1/mountpoint E.g. mountpoint -q /mnt/backup || exit 1
- jbverschoor 9y agoWhat if it gets unmounted right after the mountpoint call :)
- switch007 9y agoWhat if it gets mounted just before you run chattr +i :) I agree setting the flag is the superior option.
- xorcist 9y agoYou miss the point of making a directory immutable which doubles as a mountpoint. Mounting something just creates a new filsystem namespace over a path. It doesn't touch the existing directory. So you can safely leave the directory in question immutable, you never remove the flag, and it will only prevent writes to the directory when it is not overlaid by a mount.
- Renevith 9y agoThanks for this tip! I've been achieving this by pointing a symlink at a subdirectory that only exists when the external drive is mounted, and having my backups target that symlink. But this seems cleaner.
- wruza 9y ago>Listing a directory’s contents is controlled by the execute flag. Listing is controlled by r--. Access to content items is controlled by --x.
- emmelaich 9y agoIndeed. --x in the context of directories is typically called "search" permission rather than execute.
- agentgt 9y agoThis reminds me of the time (albeit my memory is hazy) of an issue of having to set `chattr -i` on .ssh files because even though I had the right chmod permissions SSH still would not read it. It was quite painful to figure out and I can't recall if I googled it or read it in the man pages. I believe it was because I had done something funny with the home directory and the user didn't fully own it (I believe it was a home media server). I guess apparently some SSH versions expect `chattr -i` or I guess the parent directory to be owned completely by the user (I have been meaning to look into this some day). Maybe it wasn't -i .. maybe it was +i?
- mnw21cam 9y agoThe .ssh directory and its contents must be non-writable by anyone but the user. That means the group must not have write access, even if the user is the only person in the group. Commonly, there is a group for each user with the same name, so the "fred" user will have a "fred" group with only the "fred" user being a member. This group mustn't have write access. Also, private keys must be unreadable by anyone but the user. You don't need to make the files immutable.
- agentgt 9y agoIt wasn't chattr. It was this problem with SELinux: https://stackoverflow.com/a/21636460/318174 https://stackoverflow.com/a/21636460/318174 restorecon -R -v /root/.ssh I was confused because I have used chattr with ssh files before just for added security. My memory was also hazy because I don't know much about SELinux. Hopefully I didn't misguide anyone.
- gpvos 9y agochattr appears to be a Linuxism, but TFA doesn't mention that.
- quazeekotl 9y agoBSDs also have a command that does the same thing, but its called chflags https://man.openbsd.org/chflags.1 https://man.openbsd.org/chflags.1 https://www.freebsd.org/cgi/man.cgi?query=chflags https://www.freebsd.org/cgi/man.cgi?query=chflags http://netbsd.gw.com/cgi-bin/man-cgi?chflags http://netbsd.gw.com/cgi-bin/man-cgi?chflags
- jwilk 9y agoAFIACS, chattr(1) can be compiled on BSDs too; and then it uses the chflags(2) syscall.
- emmelaich 9y ago> If the Rock Tamer, really didn’t want anyone to mess around with his rocks, he would’ve done: > # chattr +i /home/user/left-shoe/little-rock Or more traditionally, chmod +t /home/user/left-shoe though that would affect other files.
- derefr 9y agoThis is a sort of fundamental thing about POSIX: file data is attached to a pretty bare data-structure (the thing a Linux inode/BSD vnode points to), while most of the metadata is instead held in the individual dirents referencing that inode/vnode. creat(2), rename(2), and unlink(2) don't have to touch the file they're affecting; they just modify the contents of a directory, with [iv]nodes being allocated or destroyed through reference-counting as a side-effect. To put that another way: when you delete a file in POSIX, you're not writing to the file, you're just writing to the directory. (Think of a directory as just a file containing a stream of dirent data—if you have write permission on it, you can modify the dirents.) After you remove a dirent, the kernel then goes and cleans up the file if its link count has become zero—and, obviously, the kernel has permission to do that.