On Tue, May 11, 2010 at 02:07:04PM +0300, Lars Nooden wrote:
> On Tue, 11 May 2010, Nicholas Marriott wrote:
> >I had code to support forcing read-only but it wasn't well tested and
>
> Is it available still? I tried changing the permissions of the tmux
> socket directory to 750 and 710 but tmux would not allow either to
> be used, perhaps rightly so.
Yeah we should probably relax that to allow group permissions, try this.
you can also make a hardlink to the socket if necessary.
Index: tmux.c
===================================================================
RCS file: /cvsroot/tmux/tmux/tmux.c,v
retrieving revision 1.205
diff -u -p -r1.205 tmux.c
--- tmux.c 22 Apr 2010 21:48:49 -0000 1.205
+++ tmux.c 11 May 2010 11:20:20 -0000
@@ -200,7 +200,7 @@ makesockpath(const char *label)
errno = ENOTDIR;
return (NULL);
}
- if (sb.st_uid != uid || (sb.st_mode & (S_IRWXG|S_IRWXO)) != 0) {
+ if (sb.st_uid != uid || (sb.st_mode & S_IRWXO) != 0) {
errno = EACCES;
return (NULL);
}
> Here are the main use-cases I am thinking of:
>
> a) walking a group through a training session where the instructor
> has one unprivileged account and starts a tmux session in which to
> walk through an activity. The participants each have their own very
> restricted accounts (possibly with rbash or rksh) with which they
> can join the instructor's tmux session, but read-only, without any
> special tricks and follow along.
>
> b) or vice-versa, monitoring a training or work session but not
> wanting to have to worry about stray keystrokes
>
> >I'm not really convinced I want to go down the road of making security
> >guarantees in tmux, I don't really trust the way screen does it and it
> >seems rather complicated.
>
> +1 screen has the disadvantage of being first. From my rather
> uninformed vantage point, the client-server architecture of tmux
> ought to be a help. I guess it would be a lot extra to increase the
> granularity of the existing grouping.
>
> >My thinking is that you should not give access to important sessions to
> >people you do not trust. -r is a convenience against accidents and you
> >should use social mechanisms to make sure people use it (ie, apply
> >cluebat if they do not).
>
> Agreed, as in the use-case above these would not be important
> sessions or would be important sessions with reasonably reliable
> users. There are some situations where even flimsy guard rails
> help.
>
> >I make no guarantees that -r is foolproof and doesn't allow access in
> >some way.
>
> Read-only by default is more of a formality to prevent accidental
> keystrokes than as the ultimate move in proactive security: If
> there are students viewing, one of them is going to hit the keyboard
> by accident or on purpose.
>
> >It is a good idea to use separate user accounts and/or a separate tmux
> >server with -L or -S for shared stuff.
>
> Thanks for pointing out -L. That with -S and the restricted shells
> will go far. Preventing accidental keystrokes can be managed by
> accessing those particular sessions with a script which adds -r.
>
> /Lars
------------------------------------------------------------------------------
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
