On Monday 10 September 2007 21:40, Natanael Copa wrote:
> Hi,
> 
> Is it big deal to move /bin/ip to /sbin/ip?
> 
> My problem is this:
> I use busybox for my distro with vserver support. The vserver package is
> built on a standard gentoo uclibc. I suspect the util-vserver build
> scripts check what is the location for various programs, inclusive
> iproute2. The location is stored in
> a /usr/lib/util-vserver/util-vserver-vars file.
> 
> So why do I just not change this file in my util-vserver package? Well,
> in some installations the busybox ip will be enough, in others the user
> will install the original iproute2. Here comes the problems, specially
> since everything is unapcked from a package to a tmpfs during boot. The
> tools only make sure /etc survive reboots. the rest is extracted from
> cdrom.
> 
> It would be a lot easier for me to have the ip application in the same
> place as the original iproute2. In fact it makes things alot more easy
> to have the busybox applications in the same place as the original apps.
> (not first time i meet this kind of problems)

Sure, feel free to submit a patch.
But note the following:

It makes things even more easy when you do

mv /sbin/* /bin
rm -fr /sbin
ln -s /bin /sbin

I did exactly that (and similarly symlinked /usr/sbin to /usr/bin)
and am happy ever since.

Ask yourself: what is so secret in /sbin that we don't allow users
to even see? Lemme see... for example, sfdisk is there.

Does anybody seriously think that unprivileged user cannot build
his own sfdisk binary from publicly accessible source? and then run it?
And then happily receive EPERM when it tries to read raw /dev/hda?

Making users see these "secret" binaries is not dangerous,
allowing users to read them isn't dangerous either.

*Only* running them under root is dangerous, and your users
cannot do that. Unless you have stray suid bit on one
of those apps, that is. Tht is easy to fix.

IOW: having separate, hidden from users /sbin is an excellent
Unix way of feeling additional PITA for no apparent gain.
--
vda
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox

Reply via email to