@Jhesse, Ser Olmy: You haven't been paying attention... The most specific permissions
That means if the file has the same UID as the running proccess, only those permissions will be applied.. regardless of group or other permissions setting..
The system isn't traversing the file permissions until hitting an allowed or the end. Rather it checks if the UID's match. If they match those permissions are applied whathever they are. Only
when the UID's don't match, the GID's will be searched (and if they match, those will be applied)... And finally, if neither owner or group permissions apply, only
then "others" permissions will apply.
In your example, any other user from that group can cat the file, joe
can't because the file permissions forbids the owner to actually do so. Imagine if you would want a proccess to be able read a specific file (say an http server) but that file would have to get populated by a program that should be available to more than one user on the system (or even everyone, just not the webserver). If httpd (or apache, depending on your system) would be the owner with only read access, you can rest assure that the file can't get written by the apache process by mistake.. Of course, this is just an example.. There can be even more complex things done.. Imagine a write only attribute for specific processes (again, let's go to the web server) so that it can write a chat log, but not read it (weak protection in case of an exploit!? or something)..
However, take care that the owner can run 'chmod' against the file
Simple code to test (assumes umask is a default '022', bash is in /usr/bin/bash and 'ftp' user exists -- this are defaults in many, many distributions)
echo "Testing line 1" > test.txt
chmod u-r test.txt
echo "Testing line 2" >> test.txt
ls -la test.txt
sudo su -c "cat test.txt" -s /usr/bin/bash ftp
chmod u+r test.txt