Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
I doubted asking this on StackOverflow or here - it is programming related, but I'm guessing a serveradmin is better qualified to answer than a programmer... –  Konerak Mar 15 '11 at 9:11
    
Your manager is a prick. If having partitions mounted is that much of a security risk, then I recommend you take a look at the security of your infrastructure as a whole. –  Tom O'Connor Mar 15 '11 at 9:15

2 Answers 2

Sorry, but you are not right.

  1. The cost of mount and umount is not such a big thing. How oftern are the disks mounted/unmounted?
  2. Use a lock file and let the mount/umount run only once at a time.
  3. If is my server you cannot know what I'm doing there, and you cannot know anything about my scripts. So is better to have the disks unmounted.

Regards

share|improve this answer
    
thanks for your reply :) You are saying that 'mount-per-script' is not more expensive than 'permanent mount', but is there something wrong with permanent mount to start with? The script would be run about 100 times per day right now, later on it will be lots more (say 1500). –  Konerak Mar 15 '11 at 9:29
    
@Knoerak: mount+unmount should not be an expensive operation even if it ends up being done a few times per minute (though at this point you might effectively have a permanent mount anyway, if the script invocations are evenly spread throughout the day). –  David Spillett Mar 15 '11 at 10:12
    
@Konerak Is more clean to mount/umount fs. I had a lot of problems with unmounted NFS partitions (even kernel crashing), from my POV I think is better to unmount them. Anyway, this is not a rule and you can do it as you want. From Security POV, if a hacker is alredy on that system, then probably, you should be concerned how get access there. –  Sacx Mar 15 '11 at 10:18

Automounting network shares means storing credentials in a file somewhere where mount can read them (via the credentials=filename mount option in the case of cifs filesystems) - this is not necessarily a problem but could be a security concern beyond even an exploit giving someone access to the script. Storing the credentials in a files like this is more secure than keeping them in the script directly because that way there is no chance they'll appear on command lines when users search the task list with ps or similar, but it is vitally important that you make sure that only the script can read the file. You concern about users who compromise the server is no different in this situation - if they compromise it while it is live they will potentially have access to the shares anyway.

The cost of mounting and unmounting shares should not be significant - a couple of seconds (if that) at most unless you are talking to the shares over a very slow high-latency connection, and may be preferable from a security standpoint because you are not keeping the share mounted (potentially in a way which might leave it readable to other users with access) when it is not needed and the other end will be able log when your scripts authenticate and disconnect (so if there is a problem detected at the other end, it is easier to track what might have had access at the time the problem seems to have occurred).

Keeping the shares mounted despite overlapping script executions could be done by dropping a file with a random (or otherwise sufficiently unlikely to be duplicated by another script invocation) name in some location (say a directory under /var/run) and deleting that file after the actual job of the script has ended - than at the very end check that there are no other files in that directory before running umount. Another method would be to allow multiple mounts to the same share by giving each script its own mount point - this way each script would have its own share and would not interfere with the others, and you could also give each script its own authentication credentials so you have the option of managing permissions in a more fine-grained manner at the other side (perhaps some of the scripts need read+write access and some only need read-only, for instance).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.