I am working on a web-service based crypto project in JAVA. The basic idea is for the client to send a SOAP request to a servlet to encrypt data. For data transmission I am using MIME/data-handlers and I noticed that MIME stores the data being transmitted in a temporary file if the size is larger then a given amount. Even though this file will be garbage collected I would prefer it to not even be on my system. Thus, I have been writing this temporary file to /dev/null. As this is just a project it is not the end of the world if someone could still read the temp file but it made me think about a production environment where this could be a huge issue. 

Is writing to /dev/null safe and secure? Is it the same as not writing the file at all? Could someone still access the plaintext temp file that is being written ie, as it is being written?

The only real repercussion is reconnaissance - the attacker can learn login names and gecos fields (which sometimes help guess passwords) from the /etc/passwd file.

One reason for this is that, 20 years ago or so, most Unix variants shifted from keeping hashed passwords in the /etc/passwd file and moved them to /etc/shadow.  The reason for this was that /etc/passwd needed to be world readable for tools like 'finger' and 'ident' to work.  Once passwords were segregated into /etc/shadow, that file was made readable only by root.

That said, /etc/passwd remains a popular 'flag' for security analysts and hackers because it's a traditional "hey, I got what I shouldn't" file.  If you can read that, you can read other things under /etc as well, some of which can be useful to an attacker.  But it's harder to test for (say) /etc/yum.conf if you don't know if yum's on the system; /etc/passwd is always there and is a reliable test of whether access worked.

Put differently, the implicit repercussion of getting /etc/passwd is that the attacker has circumvented controls and can get arbitrary readable files, which means "I win!"*

*No actual guarantee of win, express or implied
