Date: Wed, 25 Sep 1996 18:50:57 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: terry@lambert.org (Terry Lambert) Cc: jhs@FreeBSD.org, current@FreeBSD.org, serious@FreeBSD.org, commercial@FreeBSD.org Subject: Re: Licensing Software Message-ID: <199609252250.SAA23107@skynet.ctr.columbia.edu> In-Reply-To: <199609251823.LAA06357@phaeton.artisoft.com> from "Terry Lambert" at Sep 25, 96 11:23:56 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Terry Lambert had to walk into mine and say: > > Think hard about this. It's not as easy as it may first appear. With > > PCs, you can swap out practically all the hardware, particularly ethernet > > cards, so trying to find a hardware ID value that doesn't change is a > > real challenge. > > > > Another problem with using ethernet addresses is that you need to > > grovel around in /dev/kmem in order to get them. This would require your > > executable to be setgid kmem in order to work. > > No. If you use *IP* address, you don't have this problem. No, you have an even worse problem, which is that using an IP address as a hostid won't work worth a damn, and any company that tries to get away with this will get laughed out of the business. You're assuming (I think) a unique IP address for all machines, which you're not allowed to do. Some people have machines that aren't attached to the internet and therefore have fictitious IPs. It may also be that someone has configured a bunch of standalone machines all with the same IP address (10.0.0.1, or whatever). In this case, the license key will work on all these machines, which is probably not what you want. There's also people who use dialup SLIP/PPP for their network access who may get a different IP address assigned to them each time they dial in to their ISP. So far I've only seem an IP address based licensing scheme once, for a product called Decaase (some mechanical modeling package, I think), and they only did it by accident: they assumed that the 'hostid' command in SGI IRIX did the same thing as the 'hostid' command in SunOS, and they were wrong. (The 'hostid' command in IRIX returns the system IP address (presumeably of the first available interface) in hex.) Turned out they had their own little home-brewed licensing scheme and the company only had one SGI Indy on which to test the software, hence they never made the connection. > In point of fact, there was a recent discussion on the SCO and Linux > ABI front that determined that you could get ethernet hardware addresses > for any given real ethernet interface using one of the ABI routines. > So you can forget about having to grovel kmem. Well we can read the system hostid via sysctl() (or via gethostid(), which probably just calls sysctl()); the problem is that it's never set. It would be simpler just to have the kernel set the hostid based on the MAC address of the primary interface (if there is one). The problem is that then any idiot (well, any idiot with root privs) can use sysctl to change the hostid to anything he wants. Also, just supposing you have a guy with a machine that -- horror or horrors -- has no network interface (no ethernet, no ATM, no nuthin'). Whatcha gonna do then? Not a problem for workstations since they all come (well, most all) with a network interface of some sort, but that's not strictly true of PCs. > I specifically referenced IP addresses in my discussion because: And I'm specifically telling you that you plain can't use IP addresses, period, but... > 1) ifconfig will fail to operate if you hack the interface > it uses so that it lies about IP address to your license > daemon. So then I'll just hack ifconfig too. I've got the sources to everything, remember? Alternatively: ever see the 'twiddle with your hostid' package for SunOS/Solaris that's floating around? There are tricks there not only to change your hostid on a _per_ _process_ basis, you can also fake up IP addresses on a per process basis too. This involves some specially constructed loadable kernel modules. > 2) Your network will fail to operate if two machines are given > the same IP address; they won't both work at the same time; > it depends on who gets into what ARP table when, and even > then, it won't necessarily be functional. What if they're standalone machines. There are still plenty of those in the world: you are not allowed to say that every computer is networked together. (Of course if we're talking about licensing an application that depends on access to a network -- like a network performance monitor -- then it's a whole other story. But for things like office packages (word processor, spreadsheets, etc...), CAD, modelling or graphics things, network access is not strictly necessary.) > 3) You could safely hack the ethernet address return interface > and no one would be the wiser because no system software > components really depends on it. If you had a standalone machine or your own private network, you could change your IP address at the drop of a hat too. > 4) LANCE interfaces on DEC and Sun harware can have their address > reprogrammed. This is practically true of any ethernet card > capable of supporting DECNet or DECNet bridging/routing. The > Novell/Excellan "LANalyzer" card is one example of a PC card > which can do this. IP addresses are not carved in stone either. > 5) The ethernet address (as opposed to the IP address) is a 48 > bit value, and therefore unsuitable for use by hostid. Tell that to SGI. For the smaller machines (Indigo2, Indy, desktop Challenges), they use the last 32 bits of the ethernet address as the hostid. For the larger machines -- Onyxes, big Challenges -- they use a different scheme because the ethernet hardware is part of the IO4 board, which can be replaced. > 6) Using the IP address for the hostid return is traditional. Not on SunOS/Slowlaris it isn't. > > I also wanted to try to find a way around the awful flaw in FLEXlm that > > makes it practically worthless. It sort of worked, but I got bored with > > it after a while and let it languish. > > Heh. I forgot about that one. Yeah, that's a bit of a problem, isn't > it? I remember the day we found out about it; we were using Framemaker. Yeah, Framemaker's licensing scheme has the same flaw. Of course it also uses license passwords that are only 6 characters long. :) Actually, Framemaker's licensing scheme is kind of interesting. It doesn't depend on any hostid information at all (for floating licenses anyway; I've never had to configure a standalone/nodelocked system before). They also use RPC. When the daemon starts, it broadcasts looking for other daemons on the network that may be serving licenses for the same product and with the same license password. So if you have a server running on machine A, and you start another instance of the server on machine B using the same license file, the server on machine B will detect the presence of the server on machine A and the two server process will conspire to keep the number of available licenses constant. So, in effect, if you have a license that authorizes you to run, say, ten concurrent instances of Framemaker, you can run as many instances of the fm_fls license server on your network as you please (using the same license file) and you'll still only be able to run ten concurrent instances of Framemaker. This is 'sort of' using IP addresses, except the actual address values don't matter, which is neat because you can change the IP address of one of the license servers (or even replace it entirely) and everything will still work. This assumes, however, that all your machines are all connected on one network. If you have ten standalone machines, you can buy a single user floating license and then install the license server on each machine. Since they can't talk to each other, there's no way for them to tell if the same license password is being used somewhere else. Same thing applies to ten machines networked together in isolated groups. Each group could have its own license server. Also, you might be able to use the same license file on two networks which are connected but which are not within broadcast range of each other. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609252250.SAA23107>