-
Notifications
You must be signed in to change notification settings - Fork 163
add setgid option to projects #4872
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| unless private? # allow group to edit shared projects | ||
| root_mode += (setgid ? 0o2020 : 0o020) | ||
| end | ||
| project_dataroot.chmod(root_mode) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the calls to project_dataroot in these changes will be replaced by directory after merging with #4864
| root_mode = 0o750 | ||
| unless private? # allow group to edit shared projects | ||
| root_mode += (setgid ? 0o2020 : 0o020) | ||
| end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of this addition can we just have a ternary like
mode = setgid ? 0o2750 : 0o750 or similar?
is 0o750 + 0o020 = 770? I think we want to keep 750 so collaborators can't just wipe the entire directory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking was that it was necessary for collaborators to edit files by default. Now that I look into it I may have been mistaken
collaborators can't just wipe the entire directory
I am a bit confused on this. If we want people to have full write access to directory contents, how could we stop them from deleting things? And likewise if we make sure they don't have write access to manifest.yml for example, then wouldn't that prevent any rm -r directory wipe? I am happy though to lean on your intuition as I am a bit fresh to the mode system.
My intention was to make new files inherit 770 by default, but I think that this has to be done by umask or some other approach. Open to guidance there as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, seems like it was me who was confused. We do need 770 for shared projects. I thought that 750 would protect the directory itself, but it applies to children as well.
In any case, OK - 770 is what we want at least for shared projects. Can we account for shared projects here too and set private projects to 750?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is what the unless private? conditional is for. If a project is private root_mode is unchanged from 750, otherwise it changes into 2770 or 0770
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦♂️
johrstrom
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Fixes #4781 along the same lines as #4792. In addition to the basic addition of an attribute and checkbox, there were a few changes I made as well
0oto the start of the mode, this allows the sum arguments to correctly be read as octalschgrp_directoryto the beginning ofupdate_permissions, since group changes reset the setgid bit.This also introduces group write permissions on all shared projects (outside of home directory), so the three possible values for mode are now
Since most shared projects will want it enabled, I default to
checkedon new forms, and like the group setting it is disabled on the edit form and communicates the current state. Unlike thegroup_ownerattribute, we do not automatically set this 'accurate' value in the model, but access it directly from the form. Because@project.directory.setgid?is so simple, we prefer this over @project.setgid, and so intentionally do not keep the attribute up to date with the current state, and should only ever be set duringcreateactions.