Re: prevent a dmg from being seen
Re: prevent a dmg from being seen
- Subject: Re: prevent a dmg from being seen
- From: Karl Kuehn <email@hidden>
- Date: Mon, 9 Nov 2009 20:31:07 -0800
On Nov 9, 2009, at 4:04 PM, Jim Luther wrote:
There's no way to completely keep people from seeing a file system
volume other than obfuscation.
So, the best you can do is:
1 - mount(2) the volume with the MNT_DONTBROWSE flag (with mount(1),
use the nobrowse option). That tells Mac OS X GUI code to not show
the volume in the usual places (on the Desktop, in the sidebar,
going to "My Computer", etc).
2 - Mount the volume somewhere besides /Volumes. That makes it less
likely that the user will navigate to the volume and see its contents.
In any event, the volume will show up in terminal to the mount(1)
command, and if the user uses "Go to folder..." in the Finder and
enters the path to the volume, they'll see its content.
Once the volume has been seen by the File Manager or by the new
CFURL code (SnowLeopard only), it will also show up in the lists of
volumes returned by FSGetVolumeInfo and the CFURL volume enumerator
(if the kCFURLEnumeratorSkipInvisibles isn't passed).
I actually have some code that goes one step further: we needed to
mount a couple of volumes that would be either read/write or read/only
(one of each) for the root user only, and inaccessible for everyone
else. The solution was to create a folder with 500 permissions owned
by root (and group wheel), then create the mount points inside there
and mount the volumes to those mount points with nobrowse. People
could still get the mount information with 'mount', but beyond the
name and the path they could not get anything. And since I was using a
launchd launchdaemon to monitor my code (and launch it) there was
little time for anyone to squeeze access through timing attacks. And
even if they did they would only have a very small window before I
closed it off again (miliseconds in my worst case... and they would
need root access anyways).
The solution worked out really well once I got all the kinks out
(these were internal volumes, and one of them was used by other
startup scripts, so some care about the timing was necessary). I wound
up coding three different versions (one in bash, one in python, and
then one in C), and even made a decent start at an open-source rewrite
when I lost that job to a layoff (but got the new job before finishing).
The code I wound up writting was very quick to re-mount things if it
found them (and would veto them if they came up once it was running,
then re-call the mount to the proper place). I even wrote out things
to /etc/fstab so that the next time it mounted it would default to the
right place. I will give you a few notes:
1) Since the mount callback does not give you the location it is
supposed to mount to (nor allow you to set this) I just vetoed
everything that matched one of my patterns (by /dev/ entry, since
these were internal disks), put them in a "allow this one" dictionary,
then called the mount again. Looking back I would have just mounted it
with the flag to bypass mount checking.
2) The way I did it I needed to handle the first bay and second bay
drives differently in Mac Pro's. This turned out to be a nasty little
piece of work. If you are going to do this talk to me and I will give
you the code I used, along with my table of entries for different
hardware (now somewhat out of date).
If you want to look over some stuff or talk it thought, I could
probably help. I am not sure what the chances that I will ever
complete that open-source project are (at least not while I have this
job).
--
Karl Kuehn
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden