From owner-freebsd-hackers Sat Mar 31 14: 0:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 4D3E537B719 for ; Sat, 31 Mar 2001 14:00:09 -0800 (PST) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.2/8.11.2) with ESMTP id f2VLwo301522; Sat, 31 Mar 2001 13:58:51 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200103312158.f2VLwo301522@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Bill Moran Cc: Greg Black , freebsd-hackers@FreeBSD.ORG Subject: Re: Security problems with access(2)? - off topic In-reply-to: Your message of "Sat, 31 Mar 2001 17:53:09 EST." <3AC65FD5.F91717BB@iowna.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 31 Mar 2001 13:58:50 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Sorry ... didn't think anyone was interested, and it's off topic, but > here it is in a nutshell: > > The client I'm working with is moving from a Novell server to a FreeBSD > server using Samba. They're very unhappy with Samba's behaviour in only > 1 respect: on the Novell server, files/directories that were not > readible by the user did not appear in the directory listing. For legacy > reasons, they have a single shared directory that contains hundreds of > directories, most of which are not accessibly to the majority of > groups/users on the system. > Samba has no option for this that I can find, and I have not been able > to produce this effect with manipulation of the filesystem permissions. > So I dug into the source code and found that the code that produces a > directory listing is relatively simple. It's simply a loop that iterates > through all the files(directories) in a directory and presents them to > the client. So, ignoring these files/directories is simply a matter of a > test for access() at the beginning of the loop that does a "continue" if > it fails on read access. > So you see ... this is probably one of the few situations where access() > is safe, since a mistake in this case does not provide any access the > object (that's handled later, in a completely seperate block of code) > > If I'm wrong, please feel free to correct me. This is actually an interesting case. The canonical answer is that you're wrong, and you should use stat(2) for this purpose. However it's fair to assume that with ACLs entering the picture, access(2) may actually given you a better answer. I would poke the TrustedBSD people to be certain about this, though. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message