Re: access() is a security hole?
From: David Schultz (dschultz@uclink.Berkeley.EDU)
Date: 10/10/02
- Next message: Ricardo Anguiano: "Re: access() is a security hole?"
- Previous message: Nickolay A. Kritsky: "Re[2]: Sendmail trojan...?"
- In reply to: Peter Jeremy: "Re: access() is a security hole?"
- Next in thread: Bruce Evans: "Re: access() is a security hole?"
- Reply: Bruce Evans: "Re: access() is a security hole?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 10 Oct 2002 12:31:38 -0700 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Peter Jeremy <peter.jeremy@alcatel.com.au>
Thus spake Peter Jeremy <peter.jeremy@alcatel.com.au>:
> On 2002-Oct-08 17:23:35 -0400, The Anarcat <anarcat@anarcat.ath.cx> wrote:
> >Also, this means that the stat() manpage should also contains a
> >similar section about its non-fd incarnations.
>
> I disagree. access(2) is specifically designed to allow setuid/setgid
> programs to validate access rights based on the real uid/gid - but is
> virtually impossible to use safely for this task because of the
> inherent race conditions.
No, access(2) is designed to allow NON-setuid programs to easily
do sanity checks without opening a file or device right away.
There's still a race condition, but it isn't typically a security
threat when all you're trying to do is prevent the user from
shooting himself in the foot. To use access() in a setuid program
is usually an error.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
- Next message: Ricardo Anguiano: "Re: access() is a security hole?"
- Previous message: Nickolay A. Kritsky: "Re[2]: Sendmail trojan...?"
- In reply to: Peter Jeremy: "Re: access() is a security hole?"
- Next in thread: Bruce Evans: "Re: access() is a security hole?"
- Reply: Bruce Evans: "Re: access() is a security hole?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]