Better permission control

ssh

#1

I am working with a small team on an free to use service and we maintain pretty fine grain permissions for new developers and as they progress in skill and experience with us they get more and more access.

Currently the permission model is:
read/write
read only
none

With pseudo restriction based on the Workspaces initial path (at least from the UI stand point)
Since we are using SSH workspace, anyone I share access with gets full shell access which is almost never desired.

What I would really love to see:

  • directory level permissions by user
  • terminal access permissions

Any way to disable Terminal in the IDE for shared access?
#2

Hi,

We currently don’t have such a feature on our roadmap.

However, here’s a few thoughts:

  • If you share a specific workspace, you can have that workspace mount a specific directory.
  • You can always disable write access on files for the ssh user using a super-user account
  • Don’t give your users write-access on github, but work trough pull-requesting

Hope that helps,
Matthijs


#3

Your suggestion would require a separate paid acct per user then or we would quickly exceeed the workspace limit… and addtional users would be ridiculously expensive for a team that relies on tiny donations to operate… A permissions feature makes a lot of sense or allowing ssh shares to use different shh credentials per user… (we already have a SSH based permissions setup that work…) I should clarify, our SSH permissions work at the SSH level, they do not work with the method of setting up shares that I was encouraged to follow when I started testing our dev setup with C9…


#4

Hi,

Well, I didn’t mean separate paid account… I meant using the guest OS (SSH box) for more fine-grained permission control.

The public SSH key gives us inbound access to your server, the user logged into the server can’t do anything with that.

That means you could create separate unix accounts, add the same public key to all of them, and create separate workspaces for each of them, all on one Cloud9 acount.

Unless we’re talking hundreds of users, of course.

Matthijs


#5

That is true I didn’t think of hijacking the existing users acct by adding a public key. I can probably work with that as we only have 7 or so active people working on our code. But I believe that exceeds the active workspace limit if they are all active at once (not likely)