Setting up NetatalkFile ServicesFile ServicesNetatalk's File ServicesNetatalk supplies AFPAFPApple Filing Protocol services.Setting up the AFP file serverAFP (the Apple Filing Protocol) is the protocol Apple Macintoshes
use for file services. The protocol has evolved over the years. The
latest changes to the protocol, called "AFP 3.3", were added with the
release of Snow LeopardSnow LeopardMac OS X 10.6 (Mac OS X 10.6).The afpd daemon offers the fileservices to Apple clients. The only
configuration file is afp.conf. It uses a ini style
configuration syntax.Mac OS X 10.5 (Leopard) added support for Time Machine backups
over AFP. Two new functions ensure that backups are written to spinning
disk, not just in the server's cache. Different host operating systems
honour this cache flushing differently. To make a volume a Time Machine
target use the volume option "".Starting with Netatalk 2.1 UNIX symlinkssymlinkUNIX symlink can be used on the server. Semantics are the same as for
eg NFS, ie they are not resolved on the server side but instead it's
completely up to the client to resolve them, resulting in links that
point somewhere inside the clients filesystem view.afp.confafp.conf is the configuration file used by
afpd to determine the behaviour and configuration of the AFP file
serverand the AFP volume that it provides.The afp.conf is divided into several
sections:[Global]The global section defines general server options[Homes]The homes section defines user home volumesAny section not called or
is interpreted as an AFP volume.For sharing user homes by defining a
section you must specify the option
which can be a simple string with the path to the parent directory of
all user homes or a regular expression.Example:[Homes]
basedir regex = /home
Now any user logging into the AFP server will have a user volume
available whos path is /home/NAME.A more complex setup would be a server with a large amount of
user homes which are split across eg two different
filesystems:/RAID1/homes/RAID2/morehomesThe following configuration is
required:[Homes]
basedir regex = /RAID./.*homes
If contains symlink, set the
canonicalized absolute path. When /home links to
/usr/home: [Homes]
basedir regex = /usr/homeFor a more detailed explanation of the available options, please
refer to the afp.conf5 man page.CNIDCNIDCatalog Node ID backendsBackendCNID backendUnlike other protocols like SMB or NFS, the AFP protocol mostly
refers to files and directories by ID and not by a path (the IDs are
also called CNID, that means Catalog Node ID). A typical AFP request
uses a directory IDDIDDirectory ID and a filename, something like "server, please
open the file named 'Test' in the directory with id 167". For
example "Aliases" on the Mac basically work by ID (with a fallback to
the absolute path in more recent AFP clients. But this applies only to
Finder, not to applications).Every file in an AFP volume has to have a unique file IDFIDFile ID, IDs must, according to the specs, never be reused, and
IDs are 32 bit numbers (Directory IDs use the same ID pool). So, after
~4 billion files/folders have been written to an AFP volume, the ID pool
is depleted and no new file can be written to the volume. No whining
please :-)Netatalk needs to map IDs to files and folders in the host
filesystem. To achieve this, several different CNID backendsCNID backend are available and can be choosed by the cnidschemespecifying a CNID backend option in the afp.conf5 configuration file. A CNID backend is basically a
database storing ID <-> name mappings.The CNID Databases are by default located in
/var/netatalk/CNID.There is a command line utility called dbd
available which can be used to verify, repair and rebuild the CNID
database.There are some CNID related things you should keep in mind when
working with netatalk:Don't nest volumesNested volumes.CNID backends are databases, so they turn afpd into a file
server/database mix.If there's no more space on the filesystem left, the
database will get corrupted. You can work around this by either
using the option and put the database
files into another location or, if you use quotas, make sure the
CNID database folder is owned by a user/group without a
quotaQuotasDisk usage quotas.Be careful with CNID databases for volumes that are mounted
via NFS. That is a pretty audacious decision to make anyway, but
putting a database there as well is really asking for trouble,
i.e. database corruption. Use the
directive to put the databases onto a local disk if you must use
NFSNFSNetwork File System mounted volumes.cdbCDB"cdb" CNID backendThe "concurrent database" backend is based on Berkeley DB. With
this backend, several afpd daemons access the CNID database directly.
Berkeley DB locking is used to synchronize access, if more than one
afpd process is active for a volume. The drawback is, that the crash
of a single afpd process might corrupt the database. cdb should only
be used when sharing home directories for a larger number of users
and it has been determined that a large number of
cnid_dbd processes is problematic.dbdDBD"dbd" CNID backendAccess to the CNID database is restricted to the cnid_dbd daemon
process. afpd processes communicate with the daemon for database reads
and updates. The probability for database corruption is practically
zero.This is the default backend since Netatalk 2.1.tdbtdb"tdb" CNID backendtdb is another persistent CNID database, it's
Samba's Trivial Database. It could be used
instead of cdb for user volumes.Only ever use it for volumes that are
not shared and accessed by multiple clients
at once !This backend is also used internally (as in-memory CNID
database) as a fallback in case opening the primary database can't be
opened, because tdb can work as in-memory database.
This of course means upon restart the CNIDs are gone.lastLast"last" CNID backendThe last backend is a in-memory tdb database. It is not
persistent. Starting with netatalk 3.0, it becomes the read
only mode automatically. This is useful e.g. for
CD-ROMs.CharsetsCharsetcharacter set/UnicodeUnicodeWhy Unicode?Internally, computers don't know anything about characters and
texts, they only know numbers. Therefore, each letter is assigned a
number. A character set, often referred to as
charset or
codepageCodepage, defines the mappings between numbers and
letters.If two or more computer systems need to communicate with each
other, the have to use the same character set. In the 1960s the
ASCIIASCIIAmerican Standard Code for Information
Interchange (American Standard Code for Information Interchange)
character set was defined by the American Standards Association. The
original form of ASCII represented 128 characters, more than enough to
cover the English alphabet and numerals. Up to date, ASCII has been
the normative character scheme used by computers.Later versions defined 256 characters to produce a more
international fluency and to include some slightly esoteric graphical
characters. Using this mode of encoding each character takes exactly
one byte. Obviously, 256 characters still wasn't enough to map all the
characters used in the various languages into one character
set.As a result localized character sets were defined later, e.g the
ISO-8859 character sets. Most operating system vendors introduced
their own characters sets to satisfy their needs, e.g. IBM defined the
codepage 437 (DOSLatinUS), Apple introduced the
MacRomanMacRomanMacRoman charset codepage and so on. The characters that were assigned
number larger than 127 were referred to as
extended characters. These character sets
conflict with another, as they use the same number for different
characters, or vice versa.Almost all of those characters sets defined 256 characters,
where the first 128 (0-127) character mappings are identical to ASCII.
As a result, communication between systems using different codepages
was effectively limited to the ASCII charset.To solve this problem new, larger character sets were defined.
To make room for more character mappings, these character sets use at
least 2 bytes to store a character. They are therefore referred to as
multibyte character sets.One standardized multibyte charset encoding scheme is known as
unicode. A big advantage
of using a multibyte charset is that you only need one. There is no
need to make sure two computers use the same charset when they are
communicating.character sets used by AppleIn the past, Apple clients used single-byte charsets to
communicate over the network. Over the years Apple defined a number of
codepages, western users will most likely be using the
MacRoman codepage.Codepages defined by Apple include:MacArabic, MacFarsiMacCentralEuropeMacChineseSimpleMacChineseTraditionalMacCroationMacCyrillicMacDevanagariMacGreekMacHebrewMacIcelandicMacJapaneseMacKoreanMacRomanMacRomanianMacThaiMacTurkishStarting with Mac OS X and AFP3, UTF-8 is used. UTF-8 encodes
Unicode characters in an ASCII compatible way, each Unicode character
is encoded into 1-6 ASCII characters. UTF-8 is therefore not really a
charset itself, it's an encoding of the Unicode charset.To complicate things, Unicode defines several normalization forms. While sambaSamba uses precomposedPrecomposedPrecomposed Unicode normalization Unicode, which most Unix tools prefer as well, Apple
decided to use the decomposedDecomposedDecomposed Unicode normalization normalization.For example lets take the German character
'ä'. Using the precomposed normalization, Unicode
maps this character to 0xE4. In decomposed normalization, 'ä' is
actually mapped to two characters, 0x61 and 0x308. 0x61 is the mapping
for an 'a', 0x308 is the mapping for a COMBINING
DIAERESIS.Netatalk refers to precomposed UTF-8 as
UTF8UTF8Netatalk's precomposed UTF-8 encoding and to decomposed UTF-8 as
UTF8-MACUTF8-MACNetatalk's decomposed UTF-8 encoding.afpd and character setsTo support new AFP 3.x and older AFP 2.x clients at the same
time, afpd needs to be able to convert between the various charsets
used. AFP 3.x clients always use UTF8-MAC, AFP 2.x clients use one of
the Apple codepages.At the time of this writing, netatalk supports the following
Apple codepages:MAC_CENTRALEUROPEMAC_CHINESE_SIMPMAC_CHINESE_TRADMAC_CYRILLICMAC_GREEKMAC_HEBREWMAC_JAPANESEMAC_KOREANMAC_ROMANMAC_TURKISHafpd handles three different character set options:unix charsetunix charsetafpd's unix charset settingThis is the codepage used internally by your operating
system. If not specified, it defaults to .
If is specified and your system support
Unix locales, afpd tries to detect the codepage. afpd uses this
codepage to read its configuration files, so you can use
extended characters for volume names, login messages, etc. see
afp.conf5.mac charsetmac charsetafpd's mac charset settingAs already mentioned, older Mac OS clients (up to AFP 2.2)
use codepages to communicate with afpd. However, there is no
support for negotiating the codepage used by the client in the
AFP protocol. If not specified otherwise, afpd assumes the
MacRoman codepage is used. In case you're
clients use another codepage, e.g.
MacCyrillic, you'll have to explicitly configure this. see
afp.conf5.vol charsetvol charsetafpd's vol charset settingThis defines the charset afpd should use for filenames on
disk. By default, it is the same as . If you have iconvIconviconv encoding conversion engine installed, you can use any iconv provided charset
as well.afpd needs a way to preserve extended macintosh
characters, or characters illegal in unix filenames, when saving
files on a unix filesystem. Earlier versions used the the so
called CAP encodingCAP encodingCAP style character encoding. An extended character (>0x7F) would be
converted to a :xx hex sequence, e.g. the Apple Logo (MacRoman:
0xF0) was saved as :f0. Some special characters will be
converted as to :xx notation as well. '/' will be encoded to
:2f, if was not specified, a leading
dot '.' will be encoded as :2e.Even though this version now uses as
the default encoding for filenames, '/' will be converted to
':'. For western users another useful setting could be
.If a character cannot be converted from the to the selected ,
afpd will save it as a CAP encoded character. For AFP3 clients,
afpd will convert the UTF8 character to first. If this conversion fails, you'll receive
a -50 error on the mac. Note: Whenever you
can, please stick with the default UTF8 volume format. see
afp.conf5.AuthenticationAuthenticationbetween AFP client and serverAFP authentication basicsApple chose a flexible model called "User Authentication
Modules"UAMUser Authentication Module (UAMs) for authentication purposes between AFP client
and server. An AFP client initially connecting to an AFP server will
ask for the list of UAMs which the server provides, and will choose
the one with strongest encryption that the client supports.Several UAMs have been developed by Apple over the time, some by
3rd-party developers.UAMs supported by NetatalkNetatalk supports the following ones by default:"No User Authent"No User Authent"No User Authent" UAM (guest access) UAM (guest access without authentication)"Cleartxt Passwrd"Cleartxt Passwrd"Cleartxt Passwrd" UAM UAM (no password encryption)"Randnum exchange"Randnum exchange"Randnum exchange" UAM/"2-Way Randnum exchange"2-Way Randnum exchange"2-Way Randnum exchange" UAM UAMs (weak password encryption, separate password
storage)"DHCAST128"DHCAST128"DHCAST128" UAM UAM (stronger password encryption)"DHX2"DHX2"DHX2" UAM UAM (successor of DHCAST128)There exist other optional UAMs as well:"PGPuam 1.0"PGPuam 1.0"PGPuam 1.0" UAMuams_pgp.so"PGPuam 1.0" UAM UAM (PGP-based authentication for pre-Mac OS X
clients. You'll also need the PGPuam
client to let this work)You'll have to add "--enable-pgp-uam"
to your configure switches to have this UAM available."Kerberos IV"Kerberos IV"Kerberos IV" UAMuams_krb4.so"Kerberos IV" UAM/"AFS Kerberos"AFS Kerberos"AFS Kerberos" UAM (Kerberos IV) UAMs (suitable to use Kerberos
v4 based authentication and AFS file servers)Use "--enable-krb4-uam" at compile time
to activate the build of this UAM."Client Krb v2"Client Krb v2"Client Krb v2" UAM (Kerberos V) UAM (Kerberos V, suitable for "Single Sign On"
Scenarios with OS X clients -- see below)"--enable-krbV-uam" will provide you
with the ability to use this UAM.You can configure which UAMs should be activated by defining
"" in section.
afpd will log which UAMs it's using and if problems
occur while activating them in either
netatalk.log or syslog at startup time.
asip-status.pl1 can be used to query the available UAMs of AFP
servers as well.Having a specific UAM available at the server does not
automatically mean that a client can use it. Client-side support is
also necessary. For older Macintoshes running Mac OS < X DHCAST128
support exists since AppleShare client 3.8.x.On OS X, there exist some client-side techniques to make the
AFP-client more verbose, so one can have a look what's happening while
negotiating the UAMs to use. Compare with this hint.Which UAMs to activate?It depends primarily on your needs and on the kind of Mac OS
versions you have to support. Basically one should try to use
DHCAST128 and DHX2 where possible because of its strength of password
encryption.Unless you really have to supply guest access to your
server's volumes ensure that you disable "No User Authent" since
it might lead accidentally to unauthorized access. In case you
must enable guest access take care that you enforce this on a per
volume base using the access controls.The "ClearTxt Passwrd" UAM is as bad as it sounds since
passwords go unencrypted over the wire. Try to avoid it at both
the server's side as well as on the client's. Note: If you want to
provide Mac OS 8/9 clients with NetBoot-services then you need
uams_cleartext.so since the AFP-client integrated into the Mac's
firmware can only deal with this basic form of
authentication.Since "Randnum exchange"/"2-Way Randnum exchange" uses only
56 bit DES for encryption it should be avoided as well. Another
disadvantage is the fact that the passwords have to be stored in
cleartext on the server and that it doesn't integrate into both
PAM scenarios or classic /etc/shadow (you have to administrate
passwords separately by using the afppasswd1 utility, if clients should use these
UAMs)"DHCAST128" or "DHX2" should be a good compromise for most
people since it combines stronger encryption with PAM
integration.Using the Kerberos VKerberos V"Client Krb v2" UAM ("Client Krb v2") UAM, it's possible to implement
real single sign on scenarios using Kerberos tickets. The password
is not sent over the network. Instead, the user password is used
to decrypt a service ticket for the appleshare server. The service
ticket contains an encryption key for the client and some
encrypted data (which only the appleshare server can decrypt). The
encrypted portion of the service ticket is sent to the server and
used to authenticate the user. Because of the way that the afpd
service principal detection is implemented, this authentication
method is vulnerable to man-in-the-middle attacks.For a more detailed overview over the technical implications of
the different UAMs, please have a look at Apple's File
Server Security pages.Using different authentication sources with specific
UAMsSome UAMs provide the ability to use different authentication
"backends", namely uams_cleartext.so,
uams_dhx.so and
uams_dhx2.so. They can use either classic Unix
passwords from /etc/passwd
(/etc/shadow) or PAM if the system supports that.
uams_cleartext.so can be symlinked to either
uams_passwd.so or
uams_pam.so, uams_dhx.so to
uams_dhx_passwd.so or
uams_dhx_pam.so and
uams_dhx2.so to
uams_dhx2_passwd.so or
uams_dhx2_pam.so.So, if it looks like this in Netatalk's UAMs folder (per default
/etc/netatalk/uams/):uams_clrtxt.so -> uams_pam.so
uams_dhx.so -> uams_dhx_pam.so
uams_dhx2.so -> uams_dhx2_pam.so then you're using PAM,
otherwise classic Unix passwords. The main advantage of using PAM is
that one can integrate Netatalk in centralized authentication
scenarios, eg. via LDAP, NIS and the like. Please always keep in mind
that the protection of your user's login credentials in such scenarios
also depends on the strength of encryption that the UAM in question
supplies. So think about eliminating weak UAMs like "ClearTxt Passwrd"
and "Randnum exchange" completely from your network.Netatalk UAM overview tableA small overview of the most common used UAMs.
Netatalk UAM overviewUAMNo User Authentuams_guest.so"No User Authent" UAM (guest
access)Cleartxt Passwrduams_cleartxt.so"Cleartxt Passwrd" UAM(2-Way) Randnum exchangeuams_randnum.so"(2-Way) Randnum exchange" UAMDHCAST128uams_dhx.so"DHCAST128" UAMDHX2uams_dhx2.so"DHX2" UAMClient Krb v2uams_gss.so"Client Krb v2" UAM (Kerberos V)pssword
lengthguest accessmax. 8 charactersmax. 8 charactersmax. 64 charactersmax. 256 charactersKerberos ticketsClient
supportbuilt-in into all Mac OS versionsbuilt-in in all Mac OS versions except 10.0. Has to be
activated explicitly in recent Mac OS X versionsbuilt-in into almost all Mac OS versionsbuilt-in since AppleShare client 3.8.4, available as a
plug-in for 3.8.3, integrated in Mac OS X' AFP clientbuilt-in since Mac OS X 10.2built-in since Mac OS X 10.2EncryptionEnables guest access without authentication between
client and server.Password will be sent in cleartext over the wire. Just
as bad as it sounds, therefore avoid at all if possible (note:
providing NetBoot services requires the ClearTxt UAM)8-byte random numbers are sent over the wire,
comparable with DES, 56 bits. Vulnerable to offline dictionary
attack. Requires passwords in clear on the server.Password will be encrypted with 128 bit SSL, user will
be authenticated against the server but not vice versa.
Therefor weak against man-in-the-middle attacks.Password will be encrypted using libgcrypt with CAST
128 in CBC mode. User will be authenticated against the server
but not vice versa. Therefor weak against man-in-the-middle
attacks.Password is not sent over the network. Due to the
service principal detection method, this authentication method
is vulnerable to man-in-the-middle attacks.Server
supportuams_guest.souams_cleartxt.souams_randnum.souams_dhx.souams_dhx2.souams_gss.soPassword
storage methodNoneEither /etc/passwd
(/etc/shadow) or PAMPasswords stored in
clear text in a separate text fileEither /etc/passwd
(/etc/shadow) or PAMEither /etc/passwd
(/etc/shadow) or PAMAt the Kerberos Key
Distribution Center*
* Have a look at this Kerberos
overviewSSH tunnelingTunneling and all sort of VPN stuff has nothing to do with AFP
authentication and UAMs in general. But since Apple introduced an
option called "Allow Secure Connections Using SSH" and many people
tend to confuse both things, we'll speak about that here too.Manually tunneling an AFP sessionThis works since the first AFP servers that spoke "AFP over
TCP" appeared in networks. One simply tunnels the remote server's
AFP port to a local port different than 548 and connects locally to
this port afterwards. On OS X this can be done byssh -l $USER $SERVER -L 10548:127.0.0.1:548 sleep 3000After establishing the tunnel one will use
"afp://127.0.0.1:10548" in the "Connect to
server" dialog. All AFP traffic including the initial connection
attempts will be sent encrypted over the wire since the local AFP
client will connect to the Mac's local port 10548 which will be
forwarded to the remote server's AFP port (we used the default 548)
over SSH.These sorts of tunnels are an ideal solution if you've to
access an AFP server providing weak authentications mechanisms
through the Internet without having the ability to use a "real" VPN.
Note that you can let ssh compress the data by
using its "-C" switch and that the tunnel endpoints can be different
from both AFP client and server (compare with the SSH documentation
for details).Automatically establishing a tunneled AFP connectionFrom Mac OS X 10.2 to 10.4, Apple added an "Allow Secure
Connections Using SSH" checkbox to the "Connect to Server" dialog.
The idea behind: When the server signals that it can be contacted by
SSH then Mac OS X' AFP client tries to establish the tunnel and
automagically sends all AFP traffic through it.But it took until the release of Mac OS X 10.3 that this
feature worked the first time... partly. In case, the SSH tunnel
can't be established the AFP client silently fell back to an unencrypted AFP
connection attempt.Netatalk's afpd will report that it is capable of handling SSH
tunneled AFP requests, when both ""
and "" options are set in
section (double check with asip-status.pl1 after you restarted afpd when you made changes to
the settings). But there are a couple of reasons why you don't want
to use this option at all:Tunneling TCP over TCP (as SSH does) is not the best idea.
There exist better solutions like VPNs based on the IP
layer.Since this SSH kludge isn't a normal UAM that integrates
directly into the AFP authentication mechanisms but instead uses
a single flag signalling clients whether they can try to establish a tunnel or not, it
makes life harder to see what's happening when things go
wrong.You cannot control which machines are logged on by
Netatalk tools like a macusers since all
connection attempts seem to be made from localhost.On the other side you've to limit access to afpd to
localhost only (TCP wrappers) when you want to ensure that all
AFP sessions are SSH encrypted or......when you're using 10.2 - 10.3.3 then you get the
opposite of what you'd expect: potentially unencrypted AFP
communication (including logon credentials) on the network
without a single notification that establishing the tunnel
failed. Apple fixed that not until Mac OS X 10.3.4.Encrypting all AFP sessions via SSH can lead to a
significantly higher load on the Netatalk serverACL SupportACLsACL support for AFP is implemented for ZFS ACLs on Solaris and
derived platforms and for POSIX 1e ACLs on Linux.ConfigurationFor a basic mode of operation there's nothing to configure.
Netatalk reads ACLs on the fly and calculates effective permissions
which are then send to the AFP client via the so called
UARightsUARights permission bits. On a Mac, the Finder uses these bits
to adjust permission in Finder windows. For example folder whos UNIX
mode would only result in in read-only permissions for a user will not
be displayed with a read-only icon and the user will be able to write
to the folder given the folder has an ACL giving the user write
access.By default, the effective permission of the authenticated user
are only mapped to the mentioned UARightsUARightspermission structure, not the UNIX mode. You can adjust
this behaviour with the configuration option map acls.However, neither in Finder "Get Info" windows nor in Terminal
will you be able to see the ACLs, that's a result of how ACLs in OS X
are designed. If you want to be able to display ACLs on the client,
things get more involved as you must then setup both client and server
to be part on a authentication domain (directory service, eg LDAP,
OpenDirectory). The reason is, that in OS X ACLs are bound to UUIDs,
not just uid's or gid's. Therefor afpd must be able to map every
filesystem uid and gid to a UUID so that it can return the server side
ACLs which are bound to UNIX uid and gid mapped to OS X UUIDs.Netatalk can query a directory server using LDAP queries. Either
the directory server already provides an UUID attribute for user and
groups (Active Directory, Open Directory) or you reuse an unused
attribute (or add a new one) to you directory server (eg
OpenLDAP).In detail:For Solaris/ZFS: ZFS VolumesYou should configure a ZFS ACL know for any volume you want
to use with Netatalk:aclinherit = passthrough
aclmode = passthroughFor an explanation of what this knob does and how to apply
it, check your hosts ZFS documentation (eg man zfs).Authentication DomainYour server and the clients must be part of a security
association where identity data is coming from a common source.
ACLs in Darwin are based on UUIDs and so is the ACL specification
in AFP 3.2. Therefor your source of identity data has to provide
an attribute for every user and group where a UUID is stored as a
ASCII string. In other words:you need an Open Directory Server or an LDAP server
where you store UUIDs in some attributeyour clients must be configured to use this
serveryour server should be configured to use this server via
nsswitch and PAMconfigure Netatalk via the special LDAP options for ACLs in afp.conf so that Netatalk is able
to retrieve the UUID for users and groups via LDAP search
queriesOS X ACLsWith Access Control Lists (ACLs) Mac OS X offers a powerful
extension of the traditional UNIX permissions model. An ACL is an
ordered list of Access Control Entries (ACEs) explicitly granting or
denying a set of permissions to a given user or group.Unlike UNIX permissions, which are bound to user or group IDs,
ACLs are tied to UUIDs. For this reason accessing an object's ACL
requires server and client to use a common directory service which
translates between UUIDs and user/group IDs.ACLs and UNIX permissions interact in a rather simple way. As
ACLs are optional UNIX permissions act as a default mechanism for
access control. Changing an objects's UNIX permissions will leave it's
ACL intact and modifying an ACL will never change the object's UNIX
permissions. While doing access checks, OS X first examines an
object's ACL evaluating ACEs in order until all requested rights have
been granted, a requested right has been explicitly denied by an ACE
or the end of the list has been reached. In case there is no ACL or
the permissions granted by the ACL are not sufficient to fulfill the
request, OS X next evaluates the object's UNIX permissions. Therefore
ACLs always have precedence over UNIX permissions.ZFS ACLsZFS ACLs closely match OS X ACLs. Both offer mostly identical
fine grained permissions and inheritance settings.POSIX ACLsOverviewCompared to OS X or NFSv4 ACLs, Posix ACLs represent a
different, less versatile approach to overcome the limitations of
the traditional UNIX permissions. Implementations are based on the
withdrawn Posix 1003.1e standard.The standard defines two types of ACLs. Files and directories
can have access ACLs which are consulted for access checks.
Directories can also have default ACLs irrelevant to access checks.
When a new object is created inside a directory with a default ACL,
the default ACL is applied to the new object as it's access ACL.
Subdirectories inherit default ACLs from their parent. There are no
further mechanisms of inheritance control. Architectural differences between Posix ACLs and OS X ACLs
especially involve:No fine-granular permissions model. Like UNIX
permissions Posix ACLs only differentiate between read, write
and execute permissions.Entries within an ACL are unordered.Posix ACLs can only grant rights. There is no way to
explicitly deny rights by an entry.UNIX permissions are integrated into an ACL as special
entries.Posix 1003.1e defines 6 different types of ACL entries. The
first three types are used to integrate standard UNIX permissions.
They form a minimal ACL, their presence is mandatory and only one
entry of each type is allowed within an ACL.ACL_USER_OBJ: the owner's access rights.ACL_GROUP_OBJ: the owning group's access rights.ACL_OTHER: everybody's access rights.The remaining entry types expand the traditional permissions
model:ACL_USER: grants access rights to a certain user.ACL_GROUP: grants access rights to a certain
group.ACL_MASK: limits the maximum access rights which can be
granted by entries of type ACL_GROUP_OBJ, ACL_USER and
ACL_GROUP. As the name suggests, this entry acts as a mask.
Only one ACL_MASK entry is allowed per ACL. If an ACL contains
ACL_USER or ACL_GROUP entries, an ACL_MASK entry must be
present too, otherwise it is optional.In order to maintain compatibility with applications not aware
of ACLs, Posix 1003.1e changes the semantics of system calls and
utilities which retrieve or manipulate an objects UNIX permissions.
In case an object only has a minimal ACL, the group permissions bits
of the UNIX permissions correspond to the value of the ACL_GROUP_OBJ
entry.However, if the ACL also contains an ACL_MASK entry, the
behavior of those system calls and utilities is different. The group
permissions bits of the UNIX permissions correspond to the value of
the ACL_MASK entry, i. e. calling "chmod g-w" will not only revoke
write access for the group, but for all entities which have been
granted write access by ACL_USER or ACL_GROUP entries.Mapping POSIX ACLs to OS X ACLsWhen a client wants to read an object's ACL, afpd maps it's
Posix ACL onto an equivalent OS X ACL. Writing an object's ACL
requires afpd to map an OS X ACL onto a Posix ACL. Due to
architectural restrictions of Posix ACLs, it is usually impossible
to find an exact mapping so that the result of the mapping process
will be an approximation of the original ACL's semantic.afpd silently discard entries which deny a set of
permissions because they they can't be represented within the
Posix architecture. As entries within Posix ACLs are unordered, it is
impossible to preserve order.Inheritance control is subject to severe limitations as
well:Entries with the only_inherit flag set will only
become part of the directory's default ACL.Entries with at least one of the flags
file_inherit, directory_inherit or limit_inherit set,
will become part of the directory's access and default
ACL, but the restrictions they impose on inheritance
will be ignored.The lack of a fine-granular permission model on the
Posix side will normally result in an increase of granted
permissions.As OS X clients aren't aware of the Posix 1003.1e specific
relationship between UNIX permissions and ACL_MASK, afpd does not
expose this feature to the client to avoid compatibility issues and
handles *unix permissions and ACLs the same way as Apple's reference
implementation of AFP does. When an object's UNIX permissions are
requested, afpd calculates proper group rights and returns the
result together with the owner's and everybody's access rights to
the caller via "permissions" and "ua_permissions" members of the
FPUnixPrivs structure (see Apple Filing Protocol Reference, page
181). Changing an object's permissions, afpd always updates
ACL_USER_OBJ, ACL_GROUP_OBJ and ACL_OTHERS. If an ACL_MASK entry is
present too, afpd recalculates it's value so that the new group
rights become effective and existing entries of type ACL_USER or
ACL_GROUP stay intact.Filesystem Change EventsFCENetatalk includes a nifty filesystem change event mechanism where
afpd processes notfiy interested listeners about certain filesystem
event by UDP network datagrams.For the format of the UDP packets and for an example C application
that demonstrates how to use these in a listener, take a look at the
Netatalk sourcefile bin/misc/fce.c.The currently supported FCE events arefile modification (fmod)file deletion (fdel)directory deletion (ddel)file creation (fcre)directory deletion (ddel)For details on the available simple configuration options take a
look at afp.conf.Starting and stopping NetatalkThe Netatalk distribution comes with several operating system
specific startup script templates that are tailored according to the
options given to the "configure" script before compiling. Currently,
templates are provided for RedHat (sysv style), RedHat (systemd style),
SUSE (sysv style), SUSE (systemd style), Gentoo, NetBSD, Debian and
Solaris. You can select to install the generated startup script(s)
Startscriptstartup script by specifying a system type to "configure". To
automatically install startup scripts give one of the available
option to "configure".Since new releases of Linux distributions appear all the time and
the startup procedure for the other systems mentioned above might change
as well, it is probably a good idea to not blindly install a startup
script but to look at it first to see if it will work on your system. If
you use Netatalk as part of a fixed setup, like a Linux distribution, an
RPM or a BSD package, things will probably have been arranged properly for
you. The following therefore applies mostly for people who have compiled
Netatalk themselves.The following daemon need to be started by whatever startup script
mechanism is used:netatalknetatalkAdditionally, make sure that the configuration file
afp.conf is in the right place.