Date: Fri, 22 Oct 2004 08:41:21 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Seva Tonkonoh <seva_t@dslextreme.com> Cc: freebsd-fs@freebsd.org Subject: Re: acl question Message-ID: <Pine.NEB.3.96L.1041022083717.48689C-100000@fledge.watson.org> In-Reply-To: <GMEOJKNELMGDEMDJICDMMEFJCMAA.seva_t@dslextreme.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Oct 2004, Seva Tonkonoh wrote: > I am interested in the following problem: > > My process is running as root. I want to check if some user is allowed > to access a file. Can I use ACL API to achieve that, or is there any > other way? > > The process is multithreaded, so I am not sure if I can use setuid(). Currently the only reliable way to check an ACL in place on a file against a credential is to adopt that credential for the duration of the system call. As you point out, this presents a problem for traditionally (POSIX) threaded apps, as they share a single process credential (although there can be slightly weak consistency: a thread maintains its credential from the start of the system call for the duration of the system call, regardless of changes by other threads). However, as the man page for access(2) and eaccess(2) point out, you have to be very careful about having user applications performing access control checks rather than adopting the right credential, as otherwise there's a risk of nasty races. It's also worth noting, btw, that in order to evaluate an ACL, you need not just the uid, but also a couplete set of groups for the user, so setuid() alone is not enough to set up for an access control check. Is there a way you can avoid this requirement in your application, or does the need to use threads (for performance or the like) prevent taking a more process-centric model? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041022083717.48689C-100000>