From owner-freebsd-hackers Sat Mar 31 17:17:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from maxim.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 1482337B71A for ; Sat, 31 Mar 2001 17:17:48 -0800 (PST) (envelope-from gjb@gbch.net) Received: (qmail 86580 invoked by uid 1001); 1 Apr 2001 11:17:45 +1000 Message-ID: X-Posted-By: GJB-Post 2.13 09-Feb-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Date: Sun, 01 Apr 2001 11:17:45 +1000 From: Greg Black To: Bill Moran Cc: Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: Security problems with access(2)? - off topic References: <200103312158.f2VLwo301522@mass.dis.org> <3AC6676D.C5E4771B@iowna.com> In-reply-to: <3AC6676D.C5E4771B@iowna.com> of Sat, 31 Mar 2001 18:25:33 EST Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Moran wrote: | Mike Smith wrote: | > This is actually an interesting case. | | I have some interesting clients. The reality of the matter is that their | filesystem organization on the server is terrible. This could all be | solved with a properly reorganized directory hierarchy - and that was my | first suggestion when they complained. | However, it'll be cheaper for me to tweak Samba than to correct their | disorganization, since they have apps that expect things to be in | certain places, and users who aren't terribly educated (or cooperative). It seems to me that the cheapest solution is to symlink the accessible files into a new directory and to direct your application there. Then you don't need to modify anything and the symlinks can be updated whenever you like. However, since I'm sure this suggestion will result in you telling us some other as yet unrevealed detail, I'll also comment on the programming issues. | > The canonical answer is that you're wrong, and you should use stat(2) for | > this purpose. | | That's why I gave the scenerio. | | > 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. | | Another argument in favor of access() is that the fix (for the time | being) is: | if (!access(n,R_OK) ) continue; | Which is about the simplest tweak I've ever made to a program. stat() | would not take a lot more work, but being as lazy as I am, I'll use | access() now that I know it's safe in this situation. | I know nothing of ACLs, so you've just indicated that there's something | new I need to learn. I'm also going to have to get up to date with what | TrustedBSD is doing, as I haven't been watching them much. Here's some alternative simple code: if (fd = (open(n, O_RDONLY)) < 0) continue; close fd; This takes all access control into account and really does tell the truth about whether this process in its current state can open the file for reading. Forget about access(). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message