/etc/passwd and symlinks

[Paul Fox]

 > On Tuesday 06 November 2007 19:55, Paul Fox wrote:
 > > is there any reason that passwd and chpasswd shouldn't follow
 > > symlinks to find /etc/passwd?
 > > 
 > > i have a patch to allow this, and although i've written it with a
 > > CONFIG item to protect the change, i'm wondering if the
 > > configuration option is necessary.  the reason things break,
 > > currently, is that update_passwd.c creates a new copy of
 > > /etc/passwd and renames it as a final step.  this renaming breaks
 > > any existing symlink.  all other passwd-using utilities are
 > > perfectly happy with the link, so it's arguably just a bug that
 > > updates don't work.
 > 
 > I'd say having a symlinked /etc/passwd means that you probably
 > try to live with RO /etc.

or, in our case, a ram-disk /etc.  at boot time we make copies
of important configurable files in a non-volatile filesys (if there
aren't already copies there from a previous boot), and replace
the originals with symlinks.  but it amounts to the same issue.

 > > should i commit my patch with, or without, the config variable?
 > 
 > I think it doesn't need to be configurable.
 > 
 > > (can i also hear comments on putting the Config.in change near
 > > passwd/chpasswd, rather than in libbb -- is that okay?)
 > 
 > I don't like realpath for two reasons:
 > * it requires PATH_MAX size buffer (which is BIG).
 > * it eats tons of stack internally:
 > 
 > make stksizes hall of shame (uclibc static build):
 > 0x080de75d realpath [busybox_unstripped]:               12296 <=== !!?!

wow.  :-)

 > Thus I propose introducing xmalloc_readlink_recursive()
 > which does not suffer from those two problems,
 > and using it here (and elsewhere: insmod, syslogd -
 > grep for xmalloc_readlink).

okay, will do.  thanks for the review.

paul
=---------------------
 paul fox, pgf at brightstareng.com