Subject: quick guide to "hidden" folders in netatalk shares

From: Alistair Riddell <[email-masked]>
Date: Fri, 19 Oct 2001 22:58:12 +0100 (BST)

Since there seemed to be a lot of demand for such a document I have
written a quick first draft of a document listing the various folders and
files created automatically in Netatalk shares that are invisible from the
Mac.

I have given brief notes on what each folder does and what its permissions
should be.

Please e-mail me with any questions, comments or suggestions.

Special items created inside Netatalk shares

([email-masked] 19/10/01)

Inside netatalk share points you will find several files and directories
which are created automatically by the afpd process either for its own
internal use or for the internal use of the MacOS.

None of them should be directly visible in the Finder on the Mac. 

Many of them have to be writeable in order for netatalk to function
properly. This can present problems if users have shell access to the
netatalk server. At the very least, users can "hide" files inside these
writeable folders. At worst, a malicious user could confuse netatalk in a
bad way. It is unlikely that a malicious user could cause loss of another
user's data by exploiting permissions on these items.

Below is what I hope to be a comprehensive list of these files and
directories, their purpose, and a discussion of what Unix permissions
should be set on them.

Note that in general on Netatalk shares, all directories should have the
setgid bit set. This forces any new files or folders created to have the
same group as the folder they were created in.

.AppleDouble/

This directory exists inside each folder on a Netatalk share. It contains
the resource fork of each file in that folder. Its permissions should
match those of its parent directory, i.e. anyone who has write access to
the parent directory must have write access to the corresponding
.AppleDouble directory.

.AppleDesktop/

This directory exists under the top level of each share point. It contains
the "desktop database" which is the method by which the MacOS associates a
type/creator code with a particular application. Without it, documents
will lose their application-specific icons and will have a generic icon
instead. Double-clicking documents will also fail.

To allow the desktop database to be maintained correctly, any user who is
likely to copy an application on to the share must have write access to
this directory and all directories below it. 

Icon\r and .AppleDouble\Icon\r

These files will exist in any folder, including the top level of a share,
if it has a custom icon. Make them writeable to any user who should be
allowed to change that custom icon; make them read-only if you don't want
the custom icon to be changeable.

.AppleDB/
.AppleDBcnid.lock

These will exist at the top level of each sharepoint on servers that run
netatalk compiled with the new CNID DB code. Any user who has write access
to any part of the share must have full write access to this directory /
file and all the files within it otherwise the CNID DB code will not work
properly.

Network\ Trash\ Folder/

This exists at the top level of each sharepoint. This is where files that
are put in the Trash on clients go, until the Trash is emptied.

The permissions of items in this directory are a pretty complicated
subject, but basically you should make this directory and everything in it
world-writeable if you want the Trash can to work properly. If you don't
make it writeable then users will get a message "That item cannot be put
in the Trash. Do you want to delete it immediately?" if they try to put
something in the Trash.

Temporary\ Items/

This folder may exist at the top level of a sharepoint. This folder is
used by certain applications (Adobe PhotoShop among others) to store,
well, temporary items. These programs may not work correctly if this
folder is missing or not writeable, when a user tries to work on a
document stored in that Netatalk share.

TheFindByContentFolder/

This folder is used by Sherlock 2 to store information use by its Find by
Content feature. Make it writeable by users if you want to allow them to
update the Find by Content index on a netatalk share. Otherwise, make it
read-only.

-- 
Alistair Riddell - BOFH
IT Manager, George Watson's College, Edinburgh
Tel: +44 131 446 6070    Fax: +44 131 452 8594
Microsoft - because god hates us

---

From: Glenn Trewitt <[email-masked]>
Date: Sat, 20 Oct 2001 10:26:34 -0700

This is a very good start.  I have a few comments.

First of all (minor point), all of these files are fiddled with by afpd, not
netatalk.  I don't know if you want to make this distinction or not.

> same group as the folder they were created in.

This is what netatalk does, but it isn't necessary on FreeBSD systems.  On
FreeBSD (probably all BSD systems), the new directory *always* inherits the
group of the parent.  [Side note to developers - the setgid bit is confusing,
because it's purpose (for directories) in *BSD isn't documented anywhere that
I've been able to see, so having it set on those systems sends people off on
wild goose chases to figure out what it's for.  I'll bet that autoconf has a
macro to detect this behavior.]

> the parent directory must have write access to the corresponding

It's not just the resource fork, it's also the file creator/type, and any
other Mac file system information that doesn't have an analog on UNIX.  i.e.,
this file will exist, and be non-empty, even if the file has no resource
fork.

You might also mention that .Parent (in .AppleDouble) contains the Mac HFS
information for the directory.  e.g., MyFolder/.AppleDouble/.Parent contains
info for MyFolder

> in the Trash. Do you want to delete it immediately?" if they try to put

This is correct on Mac OS < X, but I was just fiddling with this from OS X,
and no combination of permission bits makes it work.  In fact, on OS X, the
Network Trash Folder is visible in the Finder, suggesting that it doesn't
treat it specially.  Has anyone seen any evidence that OS X can use the trash
can (rather than deleting immediately) with network volumes?  (The best test
would be to test file sharing/trashing behavior between an OS X client and an
OS X server, but I only have one OS X system.)

Do you want to make any mention of the files/directories in the Network Trash
Folder, such as:
    Trash Can Usage Map
    Trash Can #NN

Hope this is helpful.
    - Glenn Trewitt

---

From: Sebastian Rittau <[email-masked]>
Date: Sat, 3 Nov 2001 15:15:38 +0100

> netatalk.  I don't know if you want to make this distinction or not.

He points that out at the beginning of the document:

| Inside netatalk share points you will find several files and directories
| which are created automatically by the afpd process either for its own
| internal use or for the internal use of the MacOS.

> group of the parent.

I've added "On some operating systems, notably FreeBSD, the group owner
is always inherited from the parent directory, so the setgid bit is not
necessary."

> this file will exist, and be non-empty, even if the file has no resource

Clarified.

> information for the directory.  e.g., MyFolder/.AppleDouble/.Parent contains

Added.

> and no combination of permission bits makes it work.

I leave it like it is for now.

 - Sebastian

---

From: "Chris Garrigues" <[email-masked]>
Date: Sat, 03 Nov 2001 10:55:09 -0600

> From:  Sebastian Rittau <[email-masked]>
> Date:  Sat, 3 Nov 2001 15:15:38 +0100
>

Leland Wallace <[email-masked]> posted a message on 16 Oct 2001 which 
stated:

> The Finder trash behavior in Mac OS X does not currently work with afp 
> volumes.
> We are working on fixing it.

so I suspect that the correct thing to say is that this is currently broken 
in 10.1, but is expected to be fixed.

Chris

-- 
Chris Garrigues                 http://www.DeepEddy.Com/~cwg/
virCIO                          http://www.virCIO.Com
4314 Avenue C                   
Austin, TX  78751-3709		+1 512 374 0500

  My email address is an experiment in SPAM elimination.  For an
  explanation of what we're doing, see http://www.DeepEddy.Com/tms.html 

    The Greatest tragedy in mankind's entire history may be the
      hijacking of morality by religion.  However valuable -- even
      necessary -- that may have been in enforcing good behavior on
      primitive peoples, their association is now counterproductive.
      Yet at the very moment when they should be decoupled,
      sanctimonious nitwits are calling for a return to morals based
      on superstition.
				--- Arthur C. Clarke

---

From: Sebastian Rittau <[email-masked]>
Date: Fri, 9 Nov 2001 20:33:39 +0100

> in 10.1, but is expected to be fixed.

I will add this text:

| Unfortunately networked trash handling is broken in current versions of
| Mac OS X even if this directory is writeable. Apple is aware of this
| problem and is working on a solution.

 - Sebastian