[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Feb 2015 16:28:29 +0200
From: Timo Teras <timo.teras@....fi>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: realpath() and setfsuid programs
On Sat, 7 Feb 2015 07:32:43 -0500
Rich Felker <dalias@...c.org> wrote:
> On Sat, Feb 07, 2015 at 07:26:03AM -0500, Rich Felker wrote:
> > On Sat, Feb 07, 2015 at 09:53:54AM +0200, Timo Teras wrote:
> > > I believe they want to drop privileges so it works as also access
> > > check to the mount point directory. As realpath() in practice
> > > checks that the user has access to the entry too.
> >
> > Could you clarify what you think the security intent of this code
> > is? As far as I can tell it's nonsense. realpath is not usable for
> > much of anything security-related; in particular, it's non-atomic
> > and subject to all sorts of trickery involving renaming/moving
> > directories during its operation, even moreso when it's done
> > component-by-component in userspace.
> >
> > Why is the check not simply an ownership check for the mount point?
> > I suspect it has to do with the need to pass a pathname rather than
> > fd to mount, which is subject to renaming/moving races, but the
> > realpath call would be subject to the same and worse. Presumably
> > the correct way to do this is to open a fd to the mountpoint then
> > pass /proc/self/fd/%d to the mount function after checking
> > ownership.
>
> Or of course just using chdir and checking ownership of ".".
Agreed. In this case fuse seems to be the place needing fix. Dropping
privileges just for realpath() does not sound like the right approach.
Though, I'm wondering if the issue showing up in other places -- that
is realpath() failing if fs uid is set to something that cannot
read /proc/self/fd/...
/Timo
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
