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