Konerak's questions

We're implementing a service that needs access to three disks that reside on different servers. I have mounted the disks (2 are on windows fileservers, cifs ; 1 is on another Linux server, nfs) and the scripts now work fine.

My manager is not very pleased with the "permanent mount" and considers this a security risk: if any script on the server is compromised, the mounted disks could be accessed. He suggests that each script that needs the disks, mounts the disks at the start of the script, and umounts them at the end of the script.

I'm not very fond of this idea, but I can't convince him. Some arguments I've tried:

• mount and umount have a cost - doing them each time will make scripts run slower. (alas, I can't pinpoint the exact cost)
• What if two scripts run simultaneously, one finishes and umounts, and the other still needs the disks? (granted, semaphores or mutexes could solve that)
• If anyone compromises the server, he can access the script that mount the disk, and thus mount them himself as well. (He claims this is an 'extra layer of defense to breach').

Can someone tell me if I'm right to be wary of this mount/umount each time, or if I'm wrong and it really is the way to go - and more specifically: why?

A company we are working with has a few ridiculous security measures. One of them goes like this:

• You cannot e-mail us .zip files. If you want to transmit a .zip file, rename it to .txt.

IMHO, there is no good reason for this. I can only see two reasons to do such a thing:

• Their employees are idiots and click on every zip file, and every .exe/.vbs/britney.jpg.com file in the zipfile. By only telling the smart people to use the rename-to-.txt files trick, the stupid people pose no threat. Actually, I like this explanation.
• There is a known bug in the email software which auto-opens .zipfiles and gets infected. Renaming prevents the software to do this.

Other than that, when the .txt arrives, their user still has to re-rename it to .zip and then we are back to square 1: we have a potentially unsafe zipfile.

Am I missing something? Is there any reason why this could be a recommended practice?

We've had it a few times now. Suddenly our production server won't respond because a process is in an infinite loop, or the MySQL server stops serving new requests because one query is blocking everything...

We SSH to the server and use ps aux or top to find the culprit, or mytop or SHOW FULL PROCESSLIST in MySQL to find the offending process ID and kill it. Then offcourse we try to recreate the situation on the testserver and fix the bug.

But sometimes the server is so well hung your ps aux / top / mytop / SHOW FULL PROCESSLIST won't go through - even the admins are blocked.

What is the best way to ensure an admin can always access the server and kill offending processes or queries (both on Linux and MySQL)?

• Can we allocate priorities to different users?
• Reserve a part of the resources for root?

I've checked nice(1), but constantly having an open connection with nice -20 seems a bit excessive and difficult to work with (let alone dangerous as root).