[Rack] Baron Security
danny at spesh.com
Tue Jan 22 19:19:55 UTC 2013
Jof, could you fix your thing? It is borken -- the script doesn't have
enough permissions to write to its own log (fixed) and ttySwhatever (which
still needs to be fixed)
On Tue, Jan 22, 2013 at 1:57 AM, Jonathan Lassoff <jof at thejof.com> wrote:
> I was looking at baron on minotaur tonight and thought that some of the
> permissions were a bit too open for the codes and log file.
> Maybe we should rotate or truncate the log after a while? Seems like we're
> collecting info on users' comings and goings, and there's no real reason to
> keep that forever.
> I think we should use the existing "barons" group for allowing access to
> modify the daemons state.
> So, I did:
> sudo chmod 0660 /usr/local/share/baron/codes.txt (owned by root / barons)
> sudo chmod 0640 /usr/local/share/baron/baron.log (owned by root / root)
> The daemon is already running as root (lulz)
> `--> ps aux ...
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> root 1 0.0 0.1 24596 2556 ? Ss Jan09 0:08 /sbin/init
> root 1637 0.0 0.5 56724 10656 ? Ss Jan09 0:27
> /usr/bin/python /usr/local/share/baron/noisebridge-baron/baron.py
> --codefile /usr/local/share/baron/codes.txt --port /dev/ttyS5 --logfile
> I added a baron user:
> sudo useradd -G barons --shell /bin/sh --home-dir /nonexistant
> --no-create-home --no-user-group baron
> and then added a "setuid baron" and "setgid barons" line to
> I pushed this change and a readme to github as well:
> Now, I just need to figure out how to handle getting the daemon to reopen
> logfiles in response to a signal, so logrotate can truncate cleanly.
> Rack mailing list
> Rack at lists.noisebridge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rack