Issues with Linux and permissions.

[Spork Schivago]

So I'm creating a bash script that downloads OpenWRT, patches it to support a Vizio XWR100 router, updates the feeds, installs symbolic links for the feeds, starts make menuconfig to configure the kernel, and then compiles the kernel.

I'm attempting to create some error checking routines. For example, the scripts obtains the current working directory (where the patches are), then it checks for the vizio_xwr100 directory to see if it exists. If it does, it removes it. If not, it creates the vizio_xwr100 directory inside the current working directory. If, for whatever reason, the rm -rf vizio_xwr100 command fails, it's supposed to error out.

The patches are currently located in the /home/spork/src/vizio_xwr100_patches/ directory. That directory is owned by spork:users. To test the error checking routine, as root, I create the /home/spork/src/vizio_xwr100_patches/vizio_xwr100 subdirectory:

eugene:/home/spork/src/vizio_xwr100_patches # whoami
root
eugene:/home/spork/src/vizio_xwr100_patches # groups
root

eugene:/home/spork/src/vizio_xwr100_patches # ls -ld /home/spork/src/vizio_xwr100_patches
drwxr-xr-x 4 spork users 4096 Aug 8 15:25 /home/spork/src/vizio_xwr100_patches

eugene:/home/spork/src/vizio_xwr100_patches # ls -ld /home/spork/src/vizio_xwr100_patches/vizio_xwr100
drwxr-xr-x 2 root root 4096 Aug 8 15:25 /home/spork/src/vizio_xwr100_patches/vizio_xwr100

I then switch to the terminal where I'm spork, and I can remove that directory:

spork@eugene:~/src/vizio_xwr100_patches> whoami
spork

spork@eugene:~/src/vizio_xwr100_patches> groups
users

spork@eugene:~/src/vizio_xwr100_patches> ls -ld /home/spork/src/vizio_xwr100_patches/vizio_xwr100
drwxr-xr-x 2 root root 4096 Aug 8 15:25 /home/spork/src/vizio_xwr100_patches/vizio_xwr100

spork@eugene:~/src/vizio_xwr100_patches> rm -rf /home/spork/src/vizio_xwr100_patches/vizio_xwr100
spork@eugene:~/src/vizio_xwr100_patches>

Any ideas what's going on here? I'm not root. The directory I created as root is readable by the world and executable by the world, but it should not be removable by my user.

The id command shows I'm not root:

id
uid=1000(spork) gid=100(users) groups=100(users)

If spork, a non-privileged user can remove directories owned by root, I get a little worried. I tried reading files that I shouldn't have access to (ie, /etc/shadow) and I cannot read them.

This is what stat shows on that directory owned by root:

 File: vizio_xwr100
 Size: 4096   	Blocks: 8     IO Block: 4096  directory
Device: 804h/2052d	Inode: 57413872  Links: 2
Access: (0755/drwxr-xr-x) Uid: (  0/  root)  Gid: (  0/  root)
Access: 2017-08-08 15:36:20.041981763 -0400
Modify: 2017-08-08 15:36:20.041981763 -0400
Change: 2017-08-08 15:36:20.041981763 -0400
 Birth: -

Also, /usr/bin/rm does not have the setUID bit set.

-rwxr-xr-x 1 root root 64384 May 27 13:38 /usr/bin/rm

which rm shows me I'm using /usr/bin/rm....

Thanks!

[Spork Schivago]

Re: Issues with Linux and permissions.

I've ran some tests.

/home is owned by root:root
/home/spork is owned by spork:users
/home/spork/src is owned by spork:users

If the previous directory is owned by spork:users, and I create a directory owned by root, I can always remove it.

For example, if, as root, I create the /home/spork/src/test directory, I can remove it as spork. If I create the /home/spork/test directory as root, I can remove it as spork.

If I create the /test directory as root, and I try to remove /test as spork, I get the permission denied message.

mount shows the /home partition like this:

/dev/sda4 on /home type ext4 (rw,relatime,data=ordered)

It's an ext4 partition. mount shows the / partition like this:

/dev/sda3 on / type ext4 (rw,relatime,data=ordered)

I don't understand why this is happening. Any suggestions on further tests I can do or does anyone know why this happening? No sticky bits anywhere either....maybe it's something with ACLs? But how would I check?

[Spork Schivago]

Re: Issues with Linux and permissions.

Using getfacl, everything seems to check out.

[stj]

Re: Issues with Linux and permissions.

no idea, my issues have often been the other way around.

[Spork Schivago]

Re: Issues with Linux and permissions.

I'm going to move this over to the OpenSuSE forum. Maybe they'll have a better idea what's going on.

[eccerr0r]

Re: Issues with Linux and permissions.

I think this is normal for standard ext2fs and should be "normal" all about because you own the directory. The file itself cannot be changed however, just can be deleted or renamed.

[Spork Schivago]

Re: Issues with Linux and permissions.

This was the response I got from a user on the OpenSuSE forum:

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.

Could someone who isn't running OpenSuSE (or one of it's variants (ie, TumbleWeed)) try an experiment for me, so I can see what causes this behaviour?

Create a directory, as root, in your /home/username/ directory. Try to remove it, as a non-root user. I want to know if it's the kernel that defines this behaviour, the file system that defines it, or if it's something special with OpenSuSE. If it's something with OpenSuSE, I'm going to move to another distro. I don't like this behaviour at all.

The way I took it, it doesn't matter who owns the file or directory. If it resides in a directory that's owned by the user, the user can delete it, regardless of who owns it.

[Spork Schivago]

Re: Issues with Linux and permissions.

I think this is normal for standard ext2fs and should be "normal" all about because you own the directory. The file itself cannot be changed however, just can be deleted or renamed.

I should have refreshed the page before I posted! Is it just the ext# filesystems? Or is it all file systems?

[Spork Schivago]

Re: Issues with Linux and permissions.

I'm running Ext4 on my CentOS server as well, and it's the same there. To me, this is a bug, not a feature! If I wanted a person to be able to delete a folder owned by root, I'd give them write permission by adding them to a group, or I'd setup ACLs or something like that.

The sticky-bit....if I set that on the /home/spork directory, would that prevent spork from deleting files / folders owned by root?

[stj]

Re: Issues with Linux and permissions.

using debian, did your test and it was deletable.
permisions must be recursive - just a theory.

[eccerr0r]

Re: Issues with Linux and permissions.

I don't think it's a bug. I hate it when someone dumps files into your directory (think multi-user situation) and suddenly you can't remove your own directory because someone put a file there. Root or not root, it's annoying. If you don't want someone inadvertently removing a file, they shouldn't own the directory either. Else you have to go with ACLs.

This is filesystem/kernel dependent. I believe there are some filesystems that will honor the behavior you want, but I don't think that follows POSIX rules - when mucking with a file in a directory, if you can throw away a directory, you should be able to throw away the contents of that directory too.

If you make your directory owned by root and enabled the sticky bit, this would prevent root files from being deleted. However all directories hierarchically upwards need to be owned by root too, and this would end up breaking other programs that expect your home directory to be owned by you.

Best is to put your project in a nameless directory that has no person's account related to it and have it root owned, and sticky bit the directories that multiple users should have read/write access but not delete each others' files. Sort of like how /tmp works.

[Spork Schivago]

Re: Issues with Linux and permissions.

using debian, did your test and it was deletable.
permisions must be recursive - just a theory.

What filesystem? One of the ext's? Thanks.

[Spork Schivago]

Re: Issues with Linux and permissions.

I don't think it's a bug. I hate it when someone dumps files into your directory (think multi-user situation) and suddenly you can't remove your own directory because someone put a file there. Root or not root, it's annoying. If you don't want someone inadvertently removing a file, they shouldn't own the directory either. Else you have to go with ACLs.

This is filesystem/kernel dependent. I believe there are some filesystems that will honor the behavior you want, but I don't think that follows POSIX rules - when mucking with a file in a directory, if you can throw away a directory, you should be able to throw away the contents of that directory too.

If you make your directory owned by root and enabled the sticky bit, this would prevent root files from being deleted. However all directories hierarchically upwards need to be owned by root too, and this would end up breaking other programs that expect your home directory to be owned by you.

Best is to put your project in a nameless directory that has no person's account related to it and have it root owned, and sticky bit the directories that multiple users should have read/write access but not delete each others' files. Sort of like how /tmp works.

Your logic there makes sense to me. I don't know if I fully like it, it just feels weird to me, because I have always looked at files owned by root as being untouchable by other users, depending on what the file permissions are.

I wasn't going to make the whole /home/spork directory sticky. I was going to make the /home/spork/src directory sticky. But maybe I shouldn't be storing my source code there anyway. Maybe I should be storing it in some place like /root/src and then just sudo'ing. But I don't like compiling code or executing code as root unless I really need to.

For testing purposes at least, I was able to set the immunity bit and get the error message I was looking for.

You seem extremely knowledgeable about *nix. How much do you know about bash and bash scripts?

I want to hide stderr. I can redirect it to /dev/null. But I want to play with the actual error message.

I'll give an example:
Say I try running patch -p1 < ./my.patch but mypatch.patch doesn't exist. My normal shell is bash, and from the command line, when I run that command, I see the following error message:

bash: my.patch: No such file or directory

If I redirect stderr to /dev/null, it disappears, which is half way what I want.

Now I want to be able to write an echo statement that says something along the lines of No such file or directory. There's no way to know for certain why programs fail, I don't want to do something like this:

patch -p1 <my.patch 2>/dev/null || echo -e "patch failed for some unknown reason!\n";

I want to do something like:

patch -p1 <my.patch 2>/dev/null || echo -e "patch -p1 <my.patch failed: ${message}.\n";

Maybe there's a way to do this with a trap? For whatever reason, I cannot even redirect the stderr from patch to /dev/null. It still shows the error message:

./test2.sh: line 2: my.patch: No such file or directory

It's probably because I'm redirecting standard input from my.patch. Redirections never been my strong suite.

[eccerr0r]

Re: Issues with Linux and permissions.

offtopic as it's not a permissions problem, but the problem with redirecting is that the error that you're seeing is not coming from patch, it's coming from your current shell (you can see "bash"). Best way is to completely do away with this error as it's totally avoidable, proactively find the problem:

#!/bin/bash
PFILE=my.patch
[ -e $PFILE ] || echo "Error: $PFILE not found" && exit 1
patch -p1 < $PFILE

[stj]

Re: Issues with Linux and permissions.

What filesystem? One of the ext's? Thanks.

ext4

[Spork Schivago]

Re: Issues with Linux and permissions.

offtopic as it's not a permissions problem, but the problem with redirecting is that the error that you're seeing is not coming from patch, it's coming from your current shell (you can see "bash"). Best way is to completely do away with this error as it's totally avoidable, proactively find the problem:

#!/bin/bash
PFILE=my.patch
[ -e $PFILE ] || echo "Error: $PFILE not found" && exit 1
patch -p1 < $PFILE

That's a good idea, checking for the file, to see if it exists first. But what about other errors that I might not be able to predirect? git failing because the DNS server has crashed or github being down, etc, etc. Those are the reasons I want to try redirecting errors to /dev/null or whatever, but catch them and display a custom error message.

Stuff like cannot remove the directory, because of invalid file permissions, or cannot change to directory, stuff like that. I currently have code, where if the command fails, it'll return the error code that the program returned. But I want to be able to return the actual message.

rm -rf /whatever, if that fails, it'll return a 1, if it doesn't have permission to remove whatever. But rm -rf /whatever will actually say why it failed. This is what I want to catch.

Would variables like $1, $2, $3 hold stuff like line number of the script, the error code, the error message? Maybe something like this:

# Define some global variables.
DIRECTORY="/tmp/mydirectory"

# Trap the various signals, so we can exit cleanly.
trap "The SIGHUP signal was triggered" SIGHUP
trap "The SIGINT signal was triggered" SIGINT
trap "The SIGTERM signal was triggered" SIGTERM

# Setup our trap to catch error messages and display them.
trap 'error_function ${cmd} ${LINENO}' ERR

error_function() {
 # declare some local variables.
 local cmd="$1"
 local lineno="$2"
 local msg="$3"
 local return_code="${4:-1}"

 # Check to see if a message was received from the program,
 # if so, display it.
 if [[ -n "${msg}" ]] ; then
  # Yup, we received a message.
  echo "Error detected on line number ${lineno}. The command ${cmd} failed with the following: ${return_code}: ${msg}."
 else
  # Nope, no message.
  echo "Error detected on line number ${lineno}. The command ${cmd} failed with the following error code: ${return_code}"
 fi
 # Return control to the operating system.
 exit "${return_code}"
}

rm -rf ${DIRECTORY} 2>/dev/null || error_function "rm -rf ${DIRECTORY}" ${LINENO};

Still can't get it working properly. It displays line number and the command, and the return code, but not the actual message. Last night I was trying this, but with patch. I didn't realize that the error message wasn't coming from patch, it was coming from the shell. Thanks for that info.

Maybe I should start a new topic, but this probably isn't the best place for programming help. I might find a better forum, more about shell programming or something.

Thanks.

[Spork Schivago]

Re: Issues with Linux and permissions.

Never mind, I got it. I figured it out myself, but then I found a lib.trap.sh script that I just source. I modified it a bit to do what I want. It works good. Minus the ./scripts/feeds install -a command seems to kill the script. I think it's because the feeds command calls exit, and there's a trap that traps EXIT. Might gotta modify it some more.

Also, there's some basic checks I do in my script. Are we root? If so, display a message saying not to run the script as root and then it exits.

The trap from lib.trap.sh will catch the exit and show that was the command that triggered the trap. I want to modify the lib.trap.sh some more, so I can override that and instead of having it automatically figure out the last program and message, if I want, in my scripts, I can send a custom message and command to display.

Thanks for all the help guys!!!!!