Default Container Permissions

[smdion]

• Hey LT/Jon/Other Docker Authors
   
  We ran into a little bit of an issue with a few of our docker containers used out side the unRAID world.
   
  
  • Tried on Phusion Baseimage on containers from Sparklyballs and LinuxServer
    
  • Tried on a bare debain base image
    
  • Permissions of / on unRAID are 777
    
  • Permissions of / on other platforms are 755
    

 

Is unraid doing anything to change the permissions of the root directory?

 

TL;DR non-root users can write to / in docker containers in unRAID containers, but can't on other docker hosts.

[sparklyballs]

 

 

two identical empty debian containers....

 

same command in each....

 

in unraid the root folder of the container has 777 permissions, my VM for the same container the root of the container has 755

[saarg]

I bet that if you run the same command on unraid and the VM you will see the same result.

So the docker container inherits the permissions from the host system you run docker exec from.

Do you get the same result if you create a script, run it in the container at startup and make it write a file with the output of the command?

[saarg]

I bet that if you run the same command on unraid and the VM you will see the same result.

So the docker container inherits the permissions from the host system you run docker exec from.

Do you get the same result if you create a script, run it in the container at startup and make it write a file with the output of the command?

 

sparklyballs screenshot is VM on the left (ubuntu) and unraid on the right and its different.

I don't think you understood what I meant. Probably my wording...

My meaning was to run the command not in the docker container, but in unraid and the VM. Therefor I also suggested to make a script to run the same command in the container without exec into it since it might be that this only happens when you exec into the container.

[smdion]

I bet that if you run the same command on unraid and the VM you will see the same result.

So the docker container inherits the permissions from the host system you run docker exec from.

Do you get the same result if you create a script, run it in the container at startup and make it write a file with the output of the command?

 

sparklyballs screenshot is VM on the left (ubuntu) and unraid on the right and its different.

I don't think you understood what I meant.

My meaning was to run the command not in the docker container, but in unraid and the VM. Therefor I also suggested to make a script to run the same command in the container without exec into it since it might be that this only happens when you exec into the container.

 

 

yea.. deleted my post above. I can't read.

[sparklyballs]

I bet that if you run the same command on unraid and the VM you will see the same result.

So the docker container inherits the permissions from the host system you run docker exec from.

Do you get the same result if you create a script, run it in the container at startup and make it write a file with the output of the command?

 

that's how we found out about it....

 

we had a script that we moved to creating a folder in / called /app and cloning a git repo into a subfolder of /app on startup through init.

 

it worked fine on unraid, a non unraid user came and told us it wasn't working for him. so we did some digging and found this.

[smdion]

unRAID / is 755 as well

[saarg]

I bet that if you run the same command on unraid and the VM you will see the same result.

So the docker container inherits the permissions from the host system you run docker exec from.

Do you get the same result if you create a script, run it in the container at startup and make it write a file with the output of the command?

 

that's how we found out about it....

 

we had a script that we moved to creating a folder in / called /app and cloning a git repo into a subfolder of /app on startup through init.

 

it worked fine on unraid, a non unraid user came and told us it wasn't working for him. so we did some digging and found this.

Then I guess docker inherits the system wide umask of the system it's started on, and has nothing to do with the exec command

[sparklyballs]

I bet that if you run the same command on unraid and the VM you will see the same result.

So the docker container inherits the permissions from the host system you run docker exec from.

Do you get the same result if you create a script, run it in the container at startup and make it write a file with the output of the command?

 

that's how we found out about it....

 

we had a script that we moved to creating a folder in / called /app and cloning a git repo into a subfolder of /app on startup through init.

 

it worked fine on unraid, a non unraid user came and told us it wasn't working for him. so we did some digging and found this.

Then I guess docker inherits the system wide umask of the system it's started on, and has nothing to do with the exec command

 

if nothing else, it's something container authors should be aware of if their containers are used on other systems...

[saarg]

unRAID / is 755 as well

Mine is 777.

 

[sparklyballs]

unRAID / is 755 as well

Mine is 777.

 

 

smdion ,you freak...

 

lol.

[smdion]

unRAID / is 755 as well

Mine is 777.

 

 

Oh wait. I run a VDMK on ESXi... that could be why.

[saarg]

unRAID / is 755 as well

Mine is 777.

 

 

smdion ,you freak...

 

lol.

Somebody has to be a freak also

[smdion]

unRAID / is 755 as well

Mine is 777.

 

 

smdion ,you freak...

 

lol.

Somebody has to be a freak also

 

but then by that logic, I shouldn't be able to write to the root directory in my containers, and I can.

[sparklyballs]

unRAID / is 755 as well

Mine is 777.

 

 

smdion ,you freak...

 

lol.

Somebody has to be a freak also

 

but then by that logic, I shouldn't be able to write to the root directory in my containers, and I can.

 

i was just thinking that too.....

[saarg]

Which user are you talking about? Since root should be able to write... Or am I lost?

[smdion]

Which user are you talking about? Since root should be able to write... Or am I lost?

On unRAID non-root users can write to / in docker containers.  They can't on other docker hosts.

[saarg]

Which user are you talking about? Since root should be able to write... Or am I lost?

On unRAID non-root users can write to / in docker containers.  They can't on other docker hosts.

So we are talking about none root users writing in /. Just making sure I follow

So you manage to write to / in the container as a user that is not root? I don't think I have any explanation to that. Except for the one Sparkly had about you

[smdion]

Which user are you talking about? Since root should be able to write... Or am I lost?

On unRAID non-root users can write to / in docker containers.  They can't on other docker hosts.

So we are talking about none root users writing in /. Just making sure I follow

So you manage to write to / in the container as a user that is not root? I don't think I have any explanation to that. Except for the one Sparkly had about you

 

hahaha. Here's some background

 

Sparkly and I are writing containers under the LinuxServer.IO badge with a few others and one of the great benefits is the user script that allows you to run any program as any user/group.  This is great for non-unRAID users of our dockers.  We create a fake user called "abc" and based on system variables passed through it assigns the User ID and the Group ID.  Then the folder and the app have permissions set for the user id/group id.  Then the program is run by that user.

 

Programs install from git need to have the proper permissions to run.  Our fix was to run it in a folder called /app.  This "fix" worked on unRAID since non-root users can write to root, but for the non-unRAID users it doesn't.  We don't want to chown that folder on every boot up because depending on the size it may take a while.  And the folder contents can change because we update on startup.  So git is also run as user abc.

 

We default it to 99/100 so it works on unRAID well.

 

We are trying to figure out why unRAID lets non-root users write to /.

 

 

and also.. I am a freak

[saarg]

Which user are you talking about? Since root should be able to write... Or am I lost?

On unRAID non-root users can write to / in docker containers.  They can't on other docker hosts.

So we are talking about none root users writing in /. Just making sure I follow

So you manage to write to / in the container as a user that is not root? I don't think I have any explanation to that. Except for the one Sparkly had about you

 

hahaha. Here's some background

 

Sparkly and I are writing containers under the LinuxServer.IO badge with a few others and one of the great benefits is the user script that allows you to run any program as any user/group.  This is great for non-unRAID users of our dockers.  We create a fake user called "abc" and based on system variables passed through it assigns the User ID and the Group ID.  Then the folder and the app have permissions set for the user id/group id.  Then the program is run by that user.

 

Programs install from git need to have the proper permissions to run.  Our fix was to run it in a folder called /app.  This "fix" worked on unRAID since non-root users can write to root, but for the non-unRAID users it doesn't.  We don't want to chown that folder on every boot up because depending on the size it may take a while.  And the folder contents can change because we update on startup.  So git is also run as user abc.

 

We are trying to figure out why unRAID lets non-root users write to /.

 

 

and also.. I am a freak

 

I guess it's like that because Tom deceided it 

[limetech]

We are trying to figure out why unRAID lets non-root users write to /.

 

Because unRaid does not have users 

 

The Users page is there strictly to authenticate SMB and AFP network connections.  They are not "real" users, meaning no home directories, no login, no shell assigned, etc.  In a purely Active Directory setup you don't need any users defined on the unRaid side at all.

 

Having said that, when someone connects to a 'secure' or 'private' share, say using SMB with Windows, they are prompted for access credentials.  Here they enter the username/password of a user they have defined on unRaid side.  When files are created they will appear to belong to that user.  However, all 'users' are also in the 'users' group.  And by default, both user and group permissions are set RW, so the notion of user ownership of files is moot.

 

Note: an advanced user can manually go and clear the group permissions on a directory to prevent other 'users' from accessing.  For example, suppose we have a share called 'Backup' and inside that share we have a directory for each user:

 

/mnt/user/Backup/

/mnt/user/Backup/larry/

/mnt/user/Backup/curly/

/mnt/user/Backup/moe/

 

Each of these directories will have permissions 0777.

 

Suppose next we set security mode 'Private' for the Backup share and add larry, curly and moe as only users permitted to access the Backup share.  Great, now only those 3 can see files in Backup, but each of them can see the other's files.  To solve this we change the permissions on larry/ curly/ and moe/ to 0700.  Now they can all access the Backup share but only access the one corresponding to the login credentials provided when they connected.

 

That's the background... I realize there might need to be some changes in order to play nice with docker containers, so I'll continue to monitor this thread until something actionable is proposed  :P

[CHBMB]

This is an interesting read, makes me realise how much Linux & users/groups/permissions makes my head hurt.

 

So as I read this, this issue creates compatibility issues running "Unraid" containers on a non-Unraid host?

 

I know I'm not contributing anything useful but I am genuinely interested.

[limetech]

This is an interesting read, makes me realise how much Linux & users/groups/permissions makes my head hurt.

Try looking at active directory permissions and how they map to linux extended attributes - will make head explode.

[smdion]

We are trying to figure out why unRAID lets non-root users write to /.

 

Because unRaid does not have users 

 

That's the background... I realize there might need to be some changes in order to play nice with docker containers, so I'll continue to monitor this thread until something actionable is proposed  :P

 

This is a deja vu back to my AD question   It never occurred to me to combine the two thoughts and think that unRAID not having users would apply all the way back to / and not just in /mnt.

 

I don't think it is so much a "problem" as it is just understanding why it is.  Just more of a thought into, all these dockers that are being created for unRAID can be used by other hosts and we need to make sure that they play across all.

 

I still have a little bit of confusion as to why the path / INSIDE the docker container is 777 in unRAID, but 755 INSIDE the docker container on other hosts. Your explanation makes sense for the / path in unRAID, but not for inside the container itself where we are also seeing this. Does docker get the permissions from the host?

 

I thought the point of dockers was to have an env completely separate from the host and a consistent experience.  How is there a difference now with permissions of / inside the container.