Message-ID: <20071202184544.GK6372@mea-ext.zmailer.org>
Date:	Sun, 2 Dec 2007 20:45:44 +0200
From:	Matti Aarnio <matti.aarnio@...iler.org>
To:	Dan Kegel <dank@...el.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Relax permissions for reading hard drive serial number?

On Thu, Nov 29, 2007 at 07:46:19AM -0800, Dan Kegel wrote:
> On Nov 29, 2007 7:37 AM, Xavier Bestel <xavier.bestel@...e.fr> wrote:
> > > One sticking point is that apps like Photoshop and probably
> > > Punkbuster want to retrieve the hard drive's serial number
> >
> > So they can't be installed on a network drive ?
> 
> I think Adobe supports that, though perhaps not with the
> retail version.  Big companies with network drives are
> probably an important revenue source for them.
> 
> I haven't looked closely at what happens when you try installing
> onto network drives.  If you are really interested, it's pretty easy to
> try yourself; just run the app under wine with
> WINEDEBUG=+cdrom,+disk and look in the log for calls like
> CreateFile("\\\\.\\PhysicalDrive0", ...).
> There's some chance the code always checks drive 0 instead
> of the drive you're installing onto.

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() )



> - Dan

/Matti Aarnio
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists