Mailing List Archive: Problem with changing file permissions on Conserver machine, affecting Conserver

Our unix machines are being auditted, and all files with permissions of
"other" group write are considered BAD.

We have been given a script to prepare our machines for the audit and
eliminate all "other writable" files (it runs chmod o-w to all files
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.

I wonder if Conserver needs to have the ability to write o+w files for
locking purposes, etc?

Conserver is awesome. 7.2.7 works very well. I will be moving to 8.x.x as
soon as I upgrade the machine.

Thanks,

Greg Brown
Computer Sciences Corporation

_________________________________________________________________
It’s our best dial-up Internet access offer: 6 months @$9.95/month. Get it
now! http://join.msn.com/?page=dept/dialup

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