permission issues with ext4 partition.

English Install/Boot/Login
#1

Hi,

I’m writing a bash script that downloads OpenWRT, patches it to support a Vizio XWR100 router, compiles it, etc. It creates a directory to clone the github repository in. But first, it checks to see if the directory exists, and if it does, it removes it. Just to be on the safe side, I implemented some error checking routines. I started testing them, and then I noticed something very odd. I’ve ran these commands from the terminal window. My working directory is /home/spork/src/vizio_xwr100_patches. The /home directory is owned by root:root, and has 0755 permissions. The /home/spork directory is owned by spork:users and has 0755 permissions. The /home/spork/src directory is owned by spork:users and has 0755 permissions. The /home/spork/src/vizio_xwr100_patches is owned by spork:users and has 0755 permissions.

I create a /home/spork/src/vizio_xwr100_patches/vizio_xwr100 directory, owned by root:root, which has the 0755 permissions. I switch back to the terminal window that has spork as the user, and I’m successfully able to remove the vizio_xwr100 directory.

I ran some tests. I can create any directory in the /home/spork directory as root, and remove it with spork. spork doesn’t belong to any weird groups, just users. spork cannot access files like /etc/shadow. spork cannot remove subdirectories owned by root in the / directory. There’s no sticky bits set, rm doesn’t have the setUID bit set, there’s no ACLs on any of those directory. The /home directory is a separate Ext4 partition. The / directory is a separate Ext4 partition.

I would expect that a directory belonging to root:root that has 0755 permissions, a non-super-user shouldn’t be able to remove, regardless of what the parent directory is.

Any ideas what’s going on here? This doesn’t seem like expected behaviour. I would have expected a permission denied message when I tried to remove the 0755-permission directories owned by root that reside somewheres inside /home/spork/<whatever>.

Thanks.

#2

Because you own the directory, and you do not need to change the root-owned folder to do so.

If root places a single file in the root-owned folder, then you’re stuck. You can’t delete the file or folder, because you’d have to modify the root-owned folder listing.

Same with root owned file in your home folder. You can delete it or rename it as the directory listing is under your ownership, but you can’t change root’s file (644).

Root could set the folder or file to immutable to make it really permanent.

#3

So this is expected behaviour then? Is this a Linux implementation or is it an OpenSuSE / Tumbleweed implementation? What I mean is this the way it is with all Linux installations, regardless of the distribution that’s running? Is it the file system that determines this behaviour, the kernel, the distro, or what?

Root could set the folder or file to immutable…You mean running something like:


chattr +i filename

Then even root cannot delete it, unless root removes the immutable bit. That’ll at least allow me to test my code… I would think that if root wanted a folder to be deletable by a non-root user, they would add the user to group and give the group writable permission or maybe use ACLs, something like that. If the /home/spork directory had the sticky bit set, and was owned by spork, wouldn’t that mean that spork could delete only files owned by spork? So if I set the sticky bit, would that have a similar affect to setting the immutable bit, minus the fact that root could still delete the file?

Thanks!

#4

Yes, this is standard unix behavior (standard unix file system semantics).

Put a root owned file in that directory, and then only root can remove (because only root can remove the file).

I seem to remember that the standard trick is to put an empty root owned directory inside, with permissions 000.

#5

Yes.

You better study up on filesystem behavior before continuing then! The user owns the directory listing in question. As long as removing something from that listing doesn’t require removing something from another listing which requires additional permissions, then the entry can be deleted.

“When the sticky bit is set on a directory, only the owner and the root user can delete / rename the files or directories within that directory.” -thegeekstuff.com So no, the user can still delete an empty root folder or a single root file. Also, other users can still edit files, if they have permissions (just not delete / rename).

Sounds like you better consult with someone about what you’re trying to achieve, since it sounds like you might be on the wrong track.

#6

Thank you! The file did the trick. chmod 000 still allowed me to remove the root owned directory.

So regardless of which file system I use, so long as directory / file permissions are used, this will always happen? Switching from ext4 to something like XFS wouldn’t change the behaviour? I’m okay with the behaviour, now that I know it’s supposed to do this. I just want to know where it’s implemented now. In the filesystem modules? Is this a POSIX standard?

Thanks!

#7

Yes, that’s right. You’ve got it.

#8

Not really sure where you think I’m on the wrong track with what I’m trying to accomplish. I just noticed something I’ve never noticed before. I thought, from what you were saying, regardless of whether the directory was empty or not, so long as it was in a directory owned by the user, it could be deleted. That’s not the case. I just found out that I can create a file as root in the /home/spork/src/test directory, and if test is owned by root, spork can delete the file. But if I create a directory owned by root in the test directory, then spork cannot delete the file or directory.

I don’t really understand the reasoning behind being able to remove the file or directory (if it’s empty), but if I got something like:
/home/spork/test/test
and both test directories are empty, but are owned by root, I cannot remove them. Just wasn’t expecting it at all, but that’s why I came here, to see if there was an issue somewheres, and if there wasn’t, to try and get a better understanding of what was happening and why it was happening.

There was a typo in my previous post. We were leaving for an appointment. I meant to type setting the sticky bit on the /home/spork/vizio_xwr100_patches directory.

From the man-page entry on chmod:


RESTRICTED DELETION FLAG OR STICKY BIT
       The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type.   **For  directories,  it  prevents**
**       unprivileged  users  from  removing  or  renaming  a  file  in  the  directory unless they own the file or the directory**; this is called the
       restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp.  For regular files on some  older
       systems, the bit saves the program's text image on the swap device so it will load more quickly when run; this is called the sticky bit.

I don’t need to do that though. If I just make /home/spork/vizio_xwr100_patches directory owned by root, then any directory or file I create under that vizio_xwr100_patches directory, non-privileged users cannot delete.

In case you’re interested in what I was trying to accomplish, I was writing some error checking routines for a bash script. The script does some stuff that takes a little bit to finish. I’m compiling a cross-compiler and some packages. I’m changing things a bit. I’ll try some stuff, then start all over. Instead of removing everything from the main working directory, cloning the repository, patching the files, running various scripts in the working directory, configuring the kernel, compile the cross-compiler / kernel / packages / etc, I just wanted a simple script to do it. Then, I could just type a command, and then go play with the baby or something. Come back a few hours later, see if it’s finished, if it is, make some changes, do it all over again.

I got it finished by the way. If you guys want to see it, I’ll be happy to post it. Maybe you guys will see something I can do better and share your infinite wisdom with me? :slight_smile:

#9

Thank you!

#10

And now you will understand why I looked with amazement to your title. Permissions do not have anything to do with the file system (except maybe non-Linux file systems were they are faked at mount). They are just permissions. :wink:

#11

Okay, I’m still missing something there then.

Are you saying I can have file permissions with something like a FAT16 filesystem? Or is this what you mean by non-Linux file systems, where they’re faked at mount? I thought things like ACLs had to be selected during compile time, to by either built as a module, or directly into the kernel, for the filesystem to support ACLs, if the filesystem was capable of supporting ACLs, for example. I look at ACLs as a type of file permission. I thought it was the filesystem itself that implemented the file permissions, and then things like the kernel where responsible for honoring those permissions.

For example, if you were to look at the raw data of an Ext4 filesystem (ie, /dev/sda1, for example), I thought file permissions were stored in an inode (a pointer to the physical location on the disk) as meta-data, along with owner, group, and timestamp info. Because file system layouts differ (btrfs vs Ext4, for example), I thought it was the job of the filesystem module (or code, if it’s built directly into the kernel) to implement this. Is this wrong?

Any good sources where I can read more on this? I find a lot of google articles explaining how to use permissions, but I can’t seem to find a lot of info on how it’s physically implemented. But I think my query’s aren’t the best.

#12

There are several things here.

What I wanted to explain is that your permission problem has nothing to do with the fact that that it happened on a file system boundary. It is about permissions. And permissions are valid in the whole directory tree from / up to the end of the branches. No matter if some of the parts of the tree are on a different file system then other parts.

Thus your title “permission issues with ext4 partition.” should in fact has read something like “permission issues with files/directories”. Don’t take me wrong. It is not about “accusing” you that the title was wrong. It is about getting you (and others reading this) to understand that the same problem would be there if the file system was Btrfs or Xfs and also even if there was no separate file system, but all was on only one large file system.
It all depends on who is the owner and what are the permission for owner, group and others of the files and the directories in the path to the file.

==============================

I only mixed in the (…) about non-Linux file systems for completeness. As these file systems (FAT, NTFS, etc.) have no implementation of owning user/group and permission bits, the software that handles these file systems on a Linux system had to invent something. They implemented fake use/group/permissions that are only known as long as the no-Linux file system is mounted and they are of course never written to the file system. That is the reason why you are blocked to chmod and chown on them.
And how to determine which user/group/permissions to fake? Well, those are implemented as file system dependent mount options. At mount is specified which user is the owner of all on the file system as long as it is mounted. So the system manager could define that in /etc/fstab. But when you have a desktop and connect a non-Linux file system (e.g. an USB stick), the desktop, together with system software finds out which user is using the desktop and uses that user for the mount option. It is just all tricks.
Because in this (in fact un-Linux-like) case, one could get the impression that ownership is bound to file systems, I added my (…) for the exception to the rule.

===========================

You are correct. All these metadata (ownership by user/group, permissions, time stamps) are in the inodes. And while inodes might be different on different types of file systems (and that is indeed handled by the software modules in the Kernel that belong to the implementation of a particular type of file system), the result to the world outside the kernel is the same. POSIX demands a minimum set of these (mainly the ones above) and you will see them in e.g. an ls -l or and stat always in the same way regardless of the lay-out of the underlying inodes.

Personally I am not much interested if the permission bits are at the beginning or in the middle of an inode. As long as I am not designing a new file system type :slight_smile:

===============================

I assume that it can not be that difficult to find something on the internet on ownership and permissions. When you can understand Dutch, there is one in the Dutch language part of these forums (I can give you the link).

And I think Wikipedia is not too bad: https://en.wikipedia.org/wiki/File_system_permissions

#13

FAT16 of course has no concept of permissions or storing permissions, but yes, the driver presents a set of fake permissions that can allow or deny access.

#14

I think your explanation here really solidified it for me. I came here, because something was wrong, and I was seeking help, trying to figure out what was wrong. In this case, it my my misunderstanding of how things worked, and you took the time to explain it to me, in detail. I found a lot on google about how to change file permissions, but not much more. I think the issue has been the lack of sleep I’ve been getting. We got a little one now and my mind doesn’t necessarily function the same when I get a couple hours versus a full nights rest. I think if I were to search now, I’ll more than likely find more technical documentation on the subject. I generally try not do complicated things when I’m tired, but unfortunately, at this point in time, there aren’t too many choices. I decided to stay home and raise my daughter instead of sending her to a day care. My wife decided to continue to work. So now I try to make money out of the house.

I keep my SSH keys on a thumb drive and for my SSH servers, I have keyboard authentication disabled. I use the thumb drive sometimes in Windows, a lot of times in Linux though. Windows doesn’t understand Linux filesystems, but Linux does a dang good job of understanding Windows filesystems. So I have the thumb drive formatted with a FAT type filesystem. SSH didn’t like the security permissions of the directory that held the keys, and the permissions of the files themselves. So I had to change them. I learned that chmod didn’t work and it was mount that controlled this. Now I understand why.

I’m still struggling a bit as to why I cannot remove a directory owned by root in my /home directory, if there’s another empty directory inside of that owned by root. I have been looking at this whole non-root users being able to remove root owned files and directories in the /home directory thing as one of those hey, it’s our /home directory, we should be able to delete anything in there we want. But maybe that’s wrong? Do you know why we’re allowed to remove the files and directories in the /home/<username> dir owned by root, but so long as they don’t contain any subdirectories or files owned by root?

When I come across something I don’t understand, I try to learn more about it. That’s what I’m doing here. Trying to get a better understanding of how and why this works.

Thank you for taking the time to go in detail with your questions. It really cleared a lot of stuff up for me. I agree, my title is incorrect. At the time though, I didn’t think it was. :slight_smile:

**EDIT: Is there away to change the title of the original thread I created? Misinformation is a bad thing, and I’d hate to have someone just starting out just glance at the thread and come to the conclusion that I originally came to. I can change it for this post, but not the actual thread.

#15

I came across this with a FAT32 thumb drive I have, but forgot all about it last night. I think it’s the lack of sleep. I just didn’t make the connection. I created a udev rule that would mount the thumb-drive read-only, so I can just yank it out if I need to. I had to call mount with the umask=0177,fmask=0177 options, in order to give it the proper “fake” permissions.

#16

The devil is in the details.

Think of your home dir listing as a file. You can change that listing / file, as long as it doesn’t violate another permission implicitly. If there is an empty folder owned by $other, you can change your listing without changing $other’s listing for that directory. Yes, you can unlink and discard $other’s empty folder which doesn’t change their empty listing.

If $other’s folder is not empty, well first you have to delete the contents of that folder. This is where the buck stops. If you don’t have write access to $other’s folder, then you can’t delete whatever is in there, and in turn, you can’t unlink it from your home dir.

#17

I’ll do some tests to see about hardlinks and symlinks. I know there’s some TOCTOU attacks that *nix systems are vulnerable too. Recent Linux kernels have an option to set it so symlinks are only followed if the owners match, same with hard links, but this might create some issues of its own.

I know I can create a program with the setuid bit set and then a simple exploit that takes advantage of a symlink vulnerability in Linux. I think it’s very hard to actually take advantage of an exploit like that in the real world. If someone can set the setuid bit, they already have root access. I think finding a program with the setuid bit that can be exploited might be hard as well. I was wondering if I could create a hardlink to something, owned by root, in the home dir, and if I removed that, would it remove what it linked to, but it doesn’t. So that’s good.

Thanks for helping clear up this issue guys! I really appreciate you taking the time to explain it to me. Now I have a much better understanding of what’s going on and more importantly, how the system works.

#18

Hard links by design have the same owner. They are entries that point to the same inode and thus share the same metadata (owner, permissions, etc.).

Softlinks are a chain (at least one symlink that points to file or to a second symlink that point to …, etc.) that can be followed. Hard links are no chain and thus they can not be “followed” in the same way.

#19

Yes, I made a mistake with the hardlink kernel protection code. For some reason, I was thinking because they shared the same inode, if I deleted the hard link, it’d delete the file that it was hard linked to. This isn’t how it works though. There’s still ways to exploit the hardlinks and symlinks though. I think kernel 3.6 offered the solution by allowing people to set /proc/sys/fs/protected_hardlinks to 1 and /proc/sys/fs/protected_symlinks to 1.

Thanks.