On 2002-08-27, Solar Designer <solar@private> wrote: > On Mon, Aug 26, 2002 at 10:08:54PM +0400, Michael Tokarev wrote: > > Ok, so I created another uid, e.g. drwebb (bases), > > chowned bases/ directory to be owned by drwebb, and > > created authorized_keys file in drwebb's home directory. > > Ok, now drwebb can update virus signatures and drwebd > > can't -- exactly what it needed. > > > > But drwebb cannot reload drwebd - it can't send SIGHUP > > to a daemon due to permission problem. > > > > There are several possible solutions: [snip] > > - maybe some more I've missed. > - have the remote connect as root, with two different su -c forced > commands in root's authorized_keys. > This would avoid the two connections, but would risk full root access > in case of bugs in the forced commands (actually a script) or in more > parts of sshd. The "bugs" in the script could actually be your not > knowing certain assumptions the invoked commands might have, such as > their trusting stdin for some sort of prompts. What about: - Create a named pipe to which drwebb has write access, and drwebd read access. Have a long-running daemon running as user drwebd which blocks forever reading it. When something is received on the pipe, eat it, send SIGHUP to drwebd (possibly enfocing a rate-limit to avoid CPU-hog DoS), and restart the blocking read on the fifo. When drwebb wants to update signature sets, it first scp's all into place, and then writes to the named pipe--possibly just make that the last "file" which gets transferred; scp will copy to fifo's. This also makes it clear when file-transfers are complete as opposed to a cron job waking up and HUPing during mid-transfer, etc. (Barring the source system running multiple overlapping scp's.) Said daemon would be very simple, thus easy to write/verify. -- Hank Leininger <hlein@progressive-comp.com>
This archive was generated by hypermail 2.1.3 : Sun Jan 15 2006 - 13:43:16 PST