> 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, [EMAIL PROTECTED] _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
