Server Permissions

[martapavelka]

Marta to Jef: Dear Jef! Thank you, all programs work as expected. There is a little issue with rights.

-- The web UI link https://www.math.miami.edu/~pavelka/scpc/

In the project folder ‘~/public_html/scpc’ there is a script ‘update.php’ that updates the repository from GitHub and generates the python file. However, the web server ‘www:www’ has no rights to write into the folder.

-- The update link https://www.math.miami.edu/~pavelka/scpc/update.php

I found a small workaround by adding ‘o+w’ to files owned by ‘pavelka:user’. It works fine, but limits my work from the CLI. Using the script, each updated file is set to ‘www:user’ with ‘rw-r--r--’. In order to access such a file from CLI I need to duplicate it and force-delete the original.

Is there a simple way allowing me to manipulate files both from CLI and using the script?

Thank you again for the support! Marta

Jef to Marta: I created a new group called webby, of which pavelka and www are members.

This seemed better than granting you access to www, which could have unforseen effects.

Then I changed the group ownership of scpc to webby although I didn't change any of the files underneath.

You should be able to "chgrp webby " to change the protections of anything you need. Then we should go back and remove all the "o" write access on your stuff, because that's very very bad.

But one thing at a time, let's try to get this working.

Let me know how it goes!

-jef

[jiripavelka]

Write permissions for “o” are now removed. However group permissions of newly created files are read only (644). Therefore I am unable to manipulate files created by the script despite belonging to the same group. Would you possibly set default permissions to 664? Unless you want me to set "g+w" to each modified file explicitly in the script?

[martapavelka]

Hmm. I really don't want to change the default permissions of the www user, since I haven't thought about all that could affect. I'd like to keep any changes specific to your account.

If the timing isn't too difficult, it does seem like maybe it makes the most sense to create the files with a more limited permission and then explicitly grant greater permission later.

But I can see how that would create issues depending on how and when the files need to be written to.

The sticky bit only changes the group owner, right, so that doesn't really help. Hmm.

I know it's inelegant, but chmodding things after creation might make the most sense. Depending on how the code is structured, you could do a pull and then one batch chmod for everything. That might be the simplest solution.

But I'm open to options if you have ideas. I'll see if I can come up with another plan.

-jef

[jiripavelka]

Thank you for the fast reply. Isn't this what setfacl is for? Somewhat like this: setfacl -d -m g::rwx scpc Similarly for scpc-dev. What do you think?

[martapavelka]

I'd never heard of setfacl and it does seem to be just the thing, but ACL stuff is not enabled by default on our server, and it has to be done at the filesystem level.

Given that this would affect all user files, I don't want to be the clueless admin who turns on something he doesn't fully understand to solve one problem in one directory.

It's a cool trick, though.

I'm open to other tricks if you can think of them. I'll try to do some more research when I get more time.

I had a window of clear thought without being constantly hassled today, so I took it!

[martapavelka]

Found this...I know pretty much nothing about git, but this looks like you can change a setting in the git config that will make it do the right thing by default without having to manually chmod after the fact.

https://serverfault.com/questions/96338/specify-default-group-and-permissions-for-new-files-in-a-certain-directory

It seems like it's your exact problem, so hopefully this will be helpful to you.

Best of luck!

[jiripavelka]

Dear Jeff,

Thank you for your effort. Suggested solution follows umask value (below). As a result it currently only preserves the group similarly to the sticky bit, however limited to git. Note the php script also creates and updates files (eg. ipython transformation and logs).

-- git core.sharedRepository https://git-scm.com/docs/git-config#Documentation/git-config.txt-coresharedRepository

The bad news is that umask is set per user (and not per folder). However, even if you set umask to the desired value, your suggested solution will be limited to git operations. In contrast, using an ACL in combination with a sticky bit covers all our needs as it works on fs level.

Note: ACL only affects explicitly stated folders. Such folders are marked with a little “+” symbol within --long listing. Regarding the server security, not only it shouldn’t be an issue, but on the contrary, ACL is used to increase server security (rather than granting rights for individual users using umask etc).

If you don’t want to waste more of your time, I can introduce a separate php script that will simply set g+w for all files in a given folder on demand before working from the terminal as I originally suggested. Automated or not, the dark side of this solution is to keep granting rights forth and back every time I need to run the web while working on the terminal. ACL solves this all by design.

Let me know how you decided, Marta

[martapavelka]

The bad news is that umask is set per user (and not per folder). However, even if you set umask to the desired value, your suggested solution will be limited to git operations.

Right, because setting the umask for pavelka doesn't help. I'd have to set it for the www user, and I'm not going to touch that. Bummer.

Hmm, we're sure that's true, right? That's it's picking up the umask from the web user?

Regarding the server security, not only it shouldn’t be an issue, but on the contrary, ACL is used to increase server security (rather than granting rights for individual users using umask etc).

Turning on a new feature (especially a security one) is always a concern, particularly if you look at how often there are patches to address issues in these things. They can't be exploited if they aren't turned on.

I get your basic premise, of course, but we'd be specifically enabling this for the purpose of slackening privileges, so there can obviously be unintended consequences, particularly since I don't have the time right now to have a thorough think about all the possible implications.

The last thing we want is for there to be new, unnoticed behavior affecting something else running on the server. There's lots of stuff running on a daily basis.

I wouldn't mind setting you up on a test server to mess around, but then you wouldn't be on the department web site, which is sort of the whole point. There's too much faculty data on corsair for me to be cavalier regarding stuff like this.

But I'm totally open to any solution where the implications are confined to your account.

Sorry to be so unhelpful, but we are in the middle of a security storm right now, and the university is locking down all kinds of things we need to be productive...I don't want to give them any more ideas by having an incident!

-jef

[jiripavelka]

Dear Jef! Thank you for the reply. I fully understand your concerns and appreciate your existing help and effort. Mainly we got rid of the o+w :) The environment is working as is and I can live with the little inconvenience it requires. Let me know if you happen to get to a solution. Best, Marta