Directory permissions for Linux LNP x64 R3 cause permission error when starting up.

[tariqk]

So, as part of deploying LNP over Docker, I get the following error message when trying to run LNP as a non-root user:

Failed to get capabilities of file `LNP/utilities/dwarf_therapist/DwarfTherapist' (Operation not supported)
Traceback (most recent call last):
  File "<string>", line 12, in <module>
  File "/home/michael/Desktop/df/python_lnp/build/lnp/out00-PYZ.pyz/core.lnp", line 48, in __init__
  File "/home/michael/Desktop/df/python_lnp/build/lnp/out00-PYZ.pyz/core.errorlog", line 70, in start
  File "/home/michael/Desktop/df/python_lnp/build/lnp/out00-PYZ.pyz/core.errorlog", line 65, in redirect
IOError: [Errno 13] Permission denied: './../../../../../stdout.txt'

(reference of the issue, and workaround, here)

It turns out the ZIP file available on both DFFD and the LNP website have the same problem: some directories have their permission bits set to 700 (i.e. user full access, group no access, others no access).

The list of the affected directories can be found here.

My current workaround is to just run find /home/Urist/bin/df/ -type d -exec chmod +rx () \; after copying everything in, but I presume this wonkiness may cause trouble in other places as well, so do I go to you or @PeridexisErrant?

[lethosor]

@BeauBouchard is the person who maintains this pack. It would be best if you could install and run the pack as the same user - DF requires write access to its folder, and making the entire thing world-writable probably isn't a good idea. Maybe you could try changing the owner of the entire directory tree to the user running DF?

[tariqk]

It would be best if you could install and run the pack as the same user - DF requires write access to its folder, and making the entire thing world-writable probably isn't a good idea.

Well, I'm not too concerned, since it is a Docker container, which is separate from the rest of the OS. I was made to understand that 755 is fairly common for directories anyway (r to see the directory, x to cd into it)? The write bit's only set for the user anyway, in the end.

Maybe you could try changing the owner of the entire directory tree to the user running DF?

That's already done as part of the setup for the Docker container, seen here.

[lethosor]

Right now, from what I understand, you can't run DF as a certain user because that user doesn't have read/execute permissions. Giving those permissions to everyone else still won't work, because DF needs write access to its subfolders (and will abort on startup if it doesn't have write access, IIRC).

[tariqk]

Yeah. The only user ID who can run this would have been Urist, who had rwx permissions throughout the ~/bin/df directory, since they were the owner. The thing is, the above error message appeared, supposedly when I was running startlnp as Urist, when certain directories (specifically, I think, /bin/df/) was set to 700.

I'm going to need to check my development machine when I get back home, but the only way this would have been possible was if, at some point, PyLNP was trying to access /bin/df as something other than as Urist (maybe in trying to get a directory listing?). I'm not familiar with PyLNP's code myself, so I can't say for sure.

I did notice this though while I was inspecting the container as Urist (using docker exec -it <container-id> /bin/bash. Even as Urist I wasn't able to view or cd into the directories that were affected, unless I used sudo.

One other possibility is that Docker is running commands in the container not as Urist but as someone else. That's a possibility and I'll need to look into it later today.

[tariqk]

Okay, a bit of an update on my side:

After this commit, which does nothing to the LNP permissions, rather, just exposes the LNP directory as a volume within Docker (better to modify and add new scripts, monkey around with the directory, persist data between runs, and general hackery), the problem doesn't crop up any more.

In light of that, you may be right with the issue may not be something to do with permissions, but some weird interaction between how Docker runs and how users are represented. I'm not exactly clear, myself.

In any case, since I can't figure out what else to do with this issue, I guess I'll just close it.