On Thu, Nov 29, 2007 at 07:46:19AM -0800, Dan Kegel wrote:This lack of having stable(*) unique system identifier available to applications is one of the small details that make node locked commercial software delivery challenging thing in UNIX environments.. *) "stable" as both stable data, and stable API to get it. There is always the way of delivering such one with a physical serial number device, but for purely selfish reasons I do compare _same_ software delivered for Windows and for Linux -- the Windows version is available for free in a certain very usefull subset, while Linux version costs a few thousand dollars, and is still less functional than the free Windows subset. One UNIX software licensor has resolved this in a way that prevents successfull restore of the license file - possibly by storing stat(2) st_ino data in the license data. Forcing the license file to have any specific i-node number on UNIX filesystems is - a bit difficult. Simple-ish solution here is, of course, to run part of the software via a suid-root helper binary, which then accesses system serial number informations - and does some other usefull and necessary functionality, like find and open external USB device(s) that the software suite drives - by passing opened device handle to the caller program (**). Software installation would want to run in super-user mode to create directory for software data ( /opt/XYZ/ ) and to install the helper binaries, of course. **) I am thinking of hardware programmer tools which highly likely do not have drivers per se in Linux kernel, nor are they easy to configure for hotplug to be assigned (device chowned) to any specific user. Such suid-root tool would let non-privileged user to access the device. One fairly stable thing in UNIX systems are network card MAC addresses. That data is available without super-user privileges, and even the API to retrieve it has been stable for about whole time that Linux has had network services. One can reset the device MAC address, so it isn't as stable as license lockers would want to -- nor difficult to fake. It has one nasty feature, tough: If you have same MAC on multiple machines within same LAN, your network will all the sudden work rather poorly. Nevertheless it is *unique* data that is available to anybody wanting to pick it up, thus I do think that it is hypocritical of making all manners of other identifiers unavailable. Now that I mentioned this, most paranoid of you would of course want to make MAC address to be "privileged data", and thus change existing API. Before you do that, check how IPv6 does its address assignments, and what would it mean to system if programs can't find out its own inbound nor outbound IPv6 addresses on connected sockets ? ( -> getsockname() ) /Matti Aarnio --
| Hiten Pandya | Re: up? (emacs docbook xml ide) |
| Martin Michlmayr | Network slowdown due to CFS |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Christos Zoulas | Re: Boot device confusion |
| Manuel Bouyer | Re: NFSv3 bug |
| Anders Magnusson | Re: setsockopt() compat issue |
| Martin Husemann | Re: Compressed vnd handling tested successfully |
