security bug in busybox chown -R

Glenn L McGrath bug1 at ihug.co.nz
Fri Aug 18 15:49:21 UTC 2006


On Fri, 18 Aug 2006 16:32:35 +0200
Natanael Copa <natanael.copa at gmail.com> wrote:

> On Fri, 2006-08-18 at 15:58 +0200, Natanael Copa wrote:
> > I have discovered a bug in the chown applet.
> > 
> > The chown -R follows links.
> 
> Actually, its not the -R option that follow links. Its chown(2)
> itself.
> 
> To fix, replace chown(2) with lchown(2). The attached patch does this.
> 
> FYI. Gnu chown has a --dereference option to follow links.
> >From the gnu chown(1) man page:
> 
>        --dereference
>               Change the ownership of the target of a symbolic link
> instead of the symbolic link itself.  (New in fileutils-4.0.)
> 
> FreeBSD and OpenBSD chown(8) has:
> 
>      -L      If the -R option is specified, all symbolic links are
> followed.

In the SuSv3 spec there is a -h option which changes the id of the
symlink rather than the target, which implies the default should be to
change the target.

But then when doing recursive chowns, it has 3 different options to
specify its behaviour and states, "Unless a -H, -L, or -P option is
specified, it is unspecified which of these options will be used as the
default."

-H and -L refer to symlinks that point to directories.

-P says it should change the symlink rather than the target, so its
a -h for symlinks within your specified directory.

So in your example, maybe the admin should have done "chown -P
ncopa /home/ncopa" as -R has an unspecified functionality, but i guess
its a judgement call on what busybox should do by default with -R.



Glenn



More information about the busybox mailing list