Subject: security issue, netatalk 1.5rc2 (and/or MacOS)?

From: Lorenzo Perone <[email-masked]>
Date: Thu, 20 Dec 2001 15:30:36 +0100

Ohps, 

Since the update to rc2:
environment: parent directories and share directories with the following rights:
drwxrws--x 

### the following happens with _client: OS X 10.1.1_:

when making a new folder inside of such a directory over th Finder,
I get a new one with the following rights on the server:

drwxrwxr-x (others get read access, and group loses sticky bit)

worse yet, if I take an existing folder (drwxrws--x ) and duplicate it in the Finder, 
I get one with

drwxrwxrwx !! (as well as all the files inside, all -rwxrwxrwx)

### The following happens with  _client: OS 9.1_:

when making a new folder:

drwxrwx--- (others lose execute, group loses sticky bit)

duplicate it in the Finder makes the same as a new one on OS9.

with p8 and all asuns, afpd used to create 
drwxrws--x dirs, and 0660 files... (as expected by me at least)

now I'm quite confused ... is there a feature that started working (that I am not aware of) or a new bug?

how I'd like to be able to force this behavior, like in samba.... 

I verified this behaviour with netatalk-1.5rc2 on
SuSE Linux 7.1 / libc6 / intel as well as on LinuxPPC 2000 Q4 / libc5 /ppc.
(did-scheme: mtab, with afpd.mtab)

It DEFINITIVELY didn't happen with netatalk 1.4+asun2.14pre37, or 1.5pre8. on the same environments. 

8-!

Lorenzo

---

From: Rick Zeman <[email-masked]>
Date: Thu, 20 Dec 2001 10:11:23 -0500

> duplicate it in the Finder makes the same as a new one on OS9.

That's actually a design FEATURE in 10.1!!!  I freaked out over this a month
ago when I discovered it going from 10.1.1 to a Netware 5 server running the
AFPTCP.nlm and sent some emails off to some people at Apple and Novell.
Since it didn't affect the netatalk 1.4b2 that was being used or 9.x on the
client end, I'd (wrongly) assumed that it was a Novell problem.
I didn't hear WHY Apple consciously made that decision in 10.1, only that
they regretted it and are working with their security people to ensure that
it was changed correctly.

It only affects folder creation (and its contents), not file-only creation.
Basically, all new folders and their contents become world readable and
writeable no matter what the parent folders permissions are, as you saw.

In Netware parlance, an explicit trustee of ROOT was added with full perms
so any user, or any object in the NDS tree had full access to those files.
Horrible.

-- 
"So Long, and Thanks For All the Fish."
       --Douglas Adams
          1952-2001

---

From: Rick Zeman <[email-masked]>
Date: Thu, 20 Dec 2001 23:56:27 -0500

> it was changed correctly.

And I can't freaking believe this STILL isn't fixed in 10.1.2.  A security
problem like this?

Is this going to have to be broadcast to the whole world before Apple is
shamed into fixing such a glaring breach of security?  This is
unconscionable.

---

From: Lorenzo Perone <[email-masked]>
Date: Fri, 21 Dec 2001 12:10:56 +0100

Let apart, for a second, the rights-scandal that Apple has produced in OSX 10.1
(just because we can't change this, yet we can hope that L.W. is monitoring this thread!)

Still, I don't actually get why,
with netatalk 1.5rc2, __OS9.1__ clients don't keep the sticky bit on...

I just re-verified it across netatalk versions.

Parent folder within share: of the kind drwxrws--x

### with netatalk-1.5rc2:
A new folder, as well as a duplicate folder, produce folders like this:
(like samba without the force directory and file modes options...):

drwxrwx---

so all files and dirs created within the copied folder will have the user's primary group instead of inheriting the share's group.

### with netatalk-1.4+asun2.1.4_pre37_test,
the rights of the new folder are completely correct (from my point of view...):

drwxrws--x

### with netatalk-1.5pre38
the rights of the new folder are like this:

drwxrws---

(so the execute bit is missing, which is not as tragical as the missing sticky bit...)

Please help us out of this from the netatalk side!
(Per-share dir and file modes options....?)

Lorenzo

---

From: Jason Quigley <[email-masked]>
Date: Fri, 21 Dec 2001 16:05:00 +0100

It would be nice to be able to specify the mode in the configuration (for
each volume) like we can in Samba.

> From: Lorenzo Perone <[email-masked]>
> Date: Fri, 21 Dec 2001 12:10:56 +0100
> To: <[email-masked]>
> Cc: <[email-masked]>
> Subject: Re: security issue, netatalk 1.5rc2 (and/or MacOS)?
> Resent-From: [email-masked]
> Resent-Date: Fri, 21 Dec 2001 06:11:03 -0500 (EST)
> 
> so all files and dirs created within the copied folder will have the user's
> primary group instead of inheriting the share's group.
> 
>>> worse yet, if I take an existing folder (drwxrws--x ) and duplicate it in
>>> the
>>> Finder,
>>> I get one with
>>>

---

From: Rick Zeman <[email-masked]>
Date: Fri, 21 Dec 2001 11:12:54 -0500

On 12/21/01 6:10 AM, "Lorenzo Perone" <[email-masked]>
wrote:

This is what I was told:

> Ok, I think I understand what you are talking about.  This has already
> been reported as a bug against OS 10.1.  In that version, Finder has
> changed its behavior on copying folders so that group and world
> privileges get opened to rwx.  This was done deliberately by Finder and
> in hindsight was a bad thing to do.  Finder team is currently working
> with our security team to use a better method.  Sorry about that.

___________________________________