Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Permissions and USB key drives UNIX
I just got my first USB 'key disk' and tried using it with 10.3 to move my files between home and work. Since I work in the Terminal a lot, I immediately noticed that the MS-DOS FAT format of the key drive changes all your permissions on the files to 777 (world read-write-execute). And that when you copy the file off the drive, these permissions don't revert to their original form.

This has three bad consequences. First if you move documents this way, they are readable by all users, including the unprivileged "nobody" on your computer. Second, all your documents become binary "executables." That is, you could try to "run" them from the command line, and if they lack descriptive suffixes, then the Finder changes their icons from generic documents to the black window icon used for unix terminal commands. Third, if you click on them, the computer may try to execute the document, not open it!!! I'll note this last operation will nearly always "crash" harmlessly, but who knows. More importantly, if your Terminal window has "./" in its path, your command line may try to run the document in preference to any similarly named command in your /bin directory.

Changing back to the correct permissions is non trivial. You can't simply execute a chmod to remove the executable status, because that will make your folders inaccessible. Plus you may have actual executables you want to preserve this status on. If all of the files you are transferring are indeed plain documents or folders, then after you copy them to your HFS or unix formatted disk, you can simply pull up a Termninal widow and type:
find /yourfolder -type f -exec chmod 640 {} \;
find /yourfolder -type -d -exec chmod 755 {} \;
This will recursively set files so that they are readable by you and the group, and folders so that they are openable by anyone. It removes write/delete privileges from everyone but you. Note: don't use this blindly on an application; normally 644 would be preferred for any .app file.

An alternative approach is to instead use Disk Utility to create an HFS-formatted sparse diskimage on your USB key drive. A sparse image can expand and contract as needed, so make it the same size as your drive so it can expand to fill the drive if need be. This is less hassle than it might seem. The sparse image will be small and mount quickly when you click on it. So the extra step of opening it is not much worse than if it were just a folder on the drive, plus it has the added advantage that you can encrypt it if you like. Encrypted or not, anything placed there will retain its privileges and ownership.

Finally, you could of course reformat the USB drive to HFS but then it would not be PC compatible.
    •    
  • Currently 2.00 / 5
  You rated: 2 / 5 (7 votes cast)
 
[15,820 views]  

Permissions and USB key drives | 11 comments | Create New Account
Click here to return to the 'Permissions and USB key drives' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Permissions and USB key drives
Authored by: deleted_user18 on May 24, '04 02:22:25PM

Having "./" in your PATH deserves you some nice crashes... :-)



[ Reply to This | # ]
Permissions and USB key drives
Authored by: thecube on May 24, '04 03:24:01PM

One easy way of getting sensible permissions when transferring files from a Windows PC to unix is to compress the file(s) before copying them from the PC to your external disk. I use zip/unzip which produces sensible permissions when unpacking on unix. I expect tar/gzip/bzip2 etc would do the same.



[ Reply to This | # ]
Permissions and USB key drives
Authored by: SOX on May 25, '04 01:14:23AM

apparently you dont use command line applications much.



[ Reply to This | # ]
Permissions and USB key drives
Authored by: Spades on May 25, '04 06:48:15PM

I use them all the time. I have used them for years. I've never dared dream of putting . on my path. Why?

Because it's an extremely easy attack vector for hacking. Put a program named ls somewhere on the computer that erases the user's home directory, or worse, exploits a privilege escalation bug. User with . on the path goes to that directory and tries to get a file listing...and they're instantly hacked.

The collected wisdom of unix administrators, programmers, and users over the years says do not put . on your path. Just, don't.



[ Reply to This | # ]
Permissions and USB key drives
Authored by: thecube on May 24, '04 03:25:26PM

One easy way of getting sensible permissions when transferring files from a Windows PC to unix is to compress the file(s) before copying them from the PC to your external disk. I use zip/unzip which produces sensible permissions when unpacking on unix. I expect tar/gzip/bzip2 etc would do the same.



[ Reply to This | # ]
Permissions and USB key drives
Authored by: BradMacPro on May 24, '04 05:28:11PM

spare disk image is great for protecting Mac OS X files on the DOS volumes of USB flash drive, but not useful for use in Mac OS 9. I binhex or zip files I need useful in OS 9 and 10. DOS volumes are not kind to Mac files of many types. Mostly applications (updaters) are what I put on my Lexar JumpShot Pro



[ Reply to This | # ]
Zip removes resource forks
Authored by: SOX on May 25, '04 01:18:02AM

plain tar,zip and bzip2 remove resource forks and meta data. you can use the apple Zip archive which preserves these. But none of these is as simple as a sparse image which does not require you to have to unzip, untar and delete the archives. also it gives you drag/drop and file level control over what you are copying over.



[ Reply to This | # ]
Zip removes resource forks
Authored by: mickeysattler on Dec 22, '10 04:08:57PM
Here in almost-2011 it seems that tar no longer strips resource forks. Here's how I tested it on a folder containing pictures which have preview thumbnail resource fork data:

$ du -s pix-w-resources/
69752	pix-w-resources/
$ tar cf foo.tar pix-w-resources/
$ rm -rf pix-w-resources
$ tar xf foo.tar
$ du -s pix-w-resources
69752	pix-w-resources
$
I stumbled over this because I'm *trying* to strip resource fork data from the bazillions of photos I have which are taking up space. What *does* strip resources is:

$ find pix-w-resources -type f -name \*.jpg -print -exec cp /dev/null {}/..namedfork/rsrc \;
Which empties the resource fork to 0-length for all file with a name ending in ".jpg". Tailor as necessary, make backups beforehand, etc.

[ Reply to This | # ]
TYPO CORRECTION
Authored by: SOX on May 25, '04 10:46:09AM

there was a typo in the post:
instead of
find /yourfolder -type -d -exec chmod 755 {} \;

type
find /yourfolder -type d -exec chmod 755 {} \;



[ Reply to This | # ]
Permissions and USB key drives
Authored by: wackazong on May 25, '04 11:06:52AM

so, if you use the disk image, how can you mount that on a windows pc? and if you cannot, why dont you just format the whole thing as HFS? ok, you get the encryption, but that was not really the purpose of the hint, was it?

I always use the .zip - archive trick, works nicely for me.



[ Reply to This | # ]
answer
Authored by: SOX on May 26, '04 11:39:19AM

If you use a sparse disk image it will inflate and deflate to use only as much of the key drive as needed for its contents. the remainder of the USB key drive is thiu available for use in communicating with PCs and other things that dont use HFS. So when you need to keep permissions and other info, you place it on the sparse image and when you dont care you place it outside the sparse.

perhaps an even better idea would be to format the sparse image as UFS so that way you could possibly use it with Linix machines that can mount spareimages and keep your permisions for them too.



[ Reply to This | # ]