[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
Bryan Stansell bryan@conserver.com
Fri, 19 Dec 2003 10:23:41 -0800 (PST)
On Thu, Dec 18, 2003 at 02:44:54PM -0800, Greg Brown wrote: > identified by the audit script). I applied it to the machine running > Conserver 7.2.7, and there seemed to be a problem with a user who was > already logged on to a console while the script was running. She > could not get the <ctrl>E. escape sequence to be recognized by the > console program until after I restored the o+w file permissions. that's very bizarre. what files were you performing the chmod on? more than just conserver logfiles? i cranked up conserver on my laptop, connected, did a 'chmod 000 *.log' and was still able to do everything normally. the process has all the files open at that point anyway, so changing perms on the should have no effect until the console goes down...then it won't be able to open the logfile when it comes back up. but, all users should still be able to disconnect just fine. quickly looking at the code, the disconnect sequence shouldn't even run into file permission problems (if they really existed) until after it closes the client file descriptor...but, like i said, it already has the file open, so the perm changes shouldn't matter. if you can reproduce this easily, it would be interesting to have both the client and server running in full debug mode and looking at all that output. or, explain exactly what your setup is, what files are being changed, etc. i'd need the user running conserver, the paths to logfiles, the sequence of steps you did to cause the problem, etc. but, making sure that changing perms on conserver-only files triggers the problem would be a good first step. > I wonder if Conserver needs to have the ability to write o+w files for > locking purposes, etc? nope. it just needs standard unix permissions...so if all it's files are owned by the user it's running as, mode 600 should fine (for logfiles, 400 for the config and passwd files). all my files are actually 644...upon startup, shutdown, etc. so, there really shouldn't be a problem (unless you're changing some system file that does have an effect on IP or something...and how that could happen escapes me). Bryan