Imagine yourself a linux lab operator at a university somewhere and TrueCrypt is installed in the lab computers for students to use to access their TrueCrypt volumes.Most students will expect to have access to TrueCrypt,the GUI application as that is how most people use TrueCrypt.

Now,how exactly can you set up TrueCrypt so that a student could not use it to get root shell as i specified?.

Simple answer,you cant.

Yes,TrueCrypt gives you an option to pass the "nosuid" option.But thats like having a system that requires a password but gives you an option to not provide it with the default behavior being the option of not providing it.

The student who will sit on that computer lab with a TrueCrypt GUI window open will be the one who gets to decide if they want to set the option or not and with the option being off by default,the student will just execute the exploit without changing anything.

I should also say that i am mhogomchungu,the founder of zuluCrypt[1] that does block device encryption and also general purpose mounting with zuluMount,a tool that ships with zuluCrypt and hence i have looked at this problem very closely and for years now and i have closely followed how other FOSS projects reason with problems associated with mount command usage and their implementations to work around the problems.There are also other bunch or wrongs that TrueCrypt is doing and i know this from looking at how things are implemented "from inside" and not how they appear from outside.

Somebody using zuluCrypt to gain root shell and i will take full responsibility for it,somebody use udisks to get root shell access and i will place responsibility fully on udisks and i am fairly certain they will do the same.

[1] https://code.google.com/p/zulucrypt/