On 2000-09-07, in
http://marc.info/?l=linux-kernel&m=96836765403118&w=2, Linus wrote:
> Hmm.. I have this feeling that it would be much nicer to
> just implement the NT system calls directly.
> ...
> I wouldn't be adverse to supporting Wine better...
A few years on, Wine has matured to the point where it's
ready to run quite a few apps, even some protected by Safedisc.
One sticking point is that apps like Photoshop and probably
Punkbuster want to retrieve the hard drive's serial number,
but Linux restricts access to that info:
$ ls -l /proc/ide/hda/identify
-r-------- 1 root root 0 2007-11-29 07:05 /proc/ide/hda/identify
(And even if /proc/ide goes away, the other ways of retrieving
this info are similarly restricted to root.)
Any reason the access control on this info shouldn't be eased a bit,
e.g. make /proc/ide/*/identify be mode 444?
An alternative might be for Wine to simply fake the serial number,
but I would like to avoid that if possible.
See also http://bugs.winehq.org/show_bug.cgi?id=10018
- Dan
On Thu, 2007-11-29 at 07:13 -0800, Dan Kegel wrote:
> A few years on, Wine has matured to the point where it's
> ready to run quite a few apps, even some protected by Safedisc.
> 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 ?
Xav
On Nov 29, 2007 7:37 AM, Xavier Bestel <[email protected]> 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.
- Dan
On Nov 29, 2007 4:46 PM, Dan Kegel <[email protected]> wrote:
> On Nov 29, 2007 7:37 AM, Xavier Bestel <[email protected]> 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.
There are people who, for privacy reasons, really don't like that "unique"
unchangeable serial numbers can be retrieved by untrusted users.
You should probably chmod the file on the users system, if he is fine with
that, but not change the kernel default.
Kay
On Thursday 29 November 2007, Kay Sievers wrote:
> On Nov 29, 2007 4:46 PM, Dan Kegel <[email protected]> wrote:
> > On Nov 29, 2007 7:37 AM, Xavier Bestel <[email protected]> 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.
>
> There are people who, for privacy reasons, really don't like that "unique"
> unchangeable serial numbers can be retrieved by untrusted users.
>
> You should probably chmod the file on the users system, if he is fine with
> that, but not change the kernel default.
Seconded.
While on it, how's about exporting model/firmware/serial through
sysfs so /proc/ide/hd*/identify don't have to be used?
[PATCH] ide: add /sys/bus/ide/devices/*/{model,firmware,serial} sysfs entries
Cc: Dan Kegel <[email protected]>
Cc: Kay Sievers <[email protected]>
Cc: Xavier Bestel <[email protected]>
Cc: Andrey Borzenkov <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/ide/ide.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
Index: b/drivers/ide/ide.c
===================================================================
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -1670,10 +1670,34 @@ static ssize_t modalias_show(struct devi
return sprintf(buf, "ide:m-%s\n", media_string(drive));
}
+static ssize_t model_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ ide_drive_t *drive = to_ide_device(dev);
+ return sprintf(buf, "%s\n", drive->id->model);
+}
+
+static ssize_t firmware_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ ide_drive_t *drive = to_ide_device(dev);
+ return sprintf(buf, "%s\n", drive->id->fw_rev);
+}
+
+static ssize_t serial_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ ide_drive_t *drive = to_ide_device(dev);
+ return sprintf(buf, "%s\n", drive->id->serial_no);
+}
+
static struct device_attribute ide_dev_attrs[] = {
__ATTR_RO(media),
__ATTR_RO(drivename),
__ATTR_RO(modalias),
+ __ATTR_RO(model),
+ __ATTR_RO(firmware),
+ __ATTR(serial, 0400, serial_show, NULL),
__ATTR_NULL
};
Hi!
> http://marc.info/?l=linux-kernel&m=96836765403118&w=2, Linus wrote:
> > Hmm.. I have this feeling that it would be much nicer to
> > just implement the NT system calls directly.
> > ...
> > I wouldn't be adverse to supporting Wine better...
>
> A few years on, Wine has matured to the point where it's
> ready to run quite a few apps, even some protected by Safedisc.
> One sticking point is that apps like Photoshop and probably
> Punkbuster want to retrieve the hard drive's serial number,
> but Linux restricts access to that info:
> $ ls -l /proc/ide/hda/identify
> -r-------- 1 root root 0 2007-11-29 07:05 /proc/ide/hda/identify
> (And even if /proc/ide goes away, the other ways of retrieving
> this info are similarly restricted to root.)
>
> Any reason the access control on this info shouldn't be eased a bit,
> e.g. make /proc/ide/*/identify be mode 444?
I think conslusion was 'unchangeable machine ids are root-only'. But
perhaps you can chmod in startup scripts?
> An alternative might be for Wine to simply fake the serial number,
> but I would like to avoid that if possible.
Fake it, I'd say.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu, Nov 29, 2007 at 10:07:46PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > There are people who, for privacy reasons, really don't like that "unique"
> > unchangeable serial numbers can be retrieved by untrusted users.
> >
> > You should probably chmod the file on the users system, if he is fine with
> > that, but not change the kernel default.
>
> Seconded.
>
> While on it, how's about exporting model/firmware/serial through
> sysfs so /proc/ide/hd*/identify don't have to be used?
Nice, except that while my home workstation running 2.6.23 kernel
does have 4 SATA disks in it, plus a compact flash memory card on
PATA (boot device, while SATA-disks are JBOD in SW RAID), it has
_no_ /sys/bus/ide/, nor /proc/ide/
All devices are under /sys/bus/scsi/
Simplest way for me to pick this data is to use "hdparm -I /dev/sdX"
command. Which of course must be run as root. All it does is to open
named device, and issue one ioctl().
That ioctl() can be embedded into a suid-root helper program, or it
can even (in case of Wine) be run separately to write a text file
storing these identifier data on some Wine config file, which the
"read from physical device X" then does receive.
In my case I don't want to report any of the hard-drive serial numbers,
but rather my boot-device - a flash drive. Hard-drives do break at
some point in time, a flash drive in read-only mode does last considerably
longer.
> [PATCH] ide: add /sys/bus/ide/devices/*/{model,firmware,serial} sysfs entries
...
/Matti Aarnio
On Thu, Nov 29, 2007 at 07:46:19AM -0800, Dan Kegel wrote:
> On Nov 29, 2007 7:37 AM, Xavier Bestel <[email protected]> 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
On Dec 02, 2007, at 13:45:44, Matti Aarnio 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.
Well... There's that. There's also the fact that anybody with a
modicum of ASM programming skills can get clever with GDB and traces
from "Correct HW serial" and "Incorrect HW serial" can write a 10-
line GDB script to make it work regardless. I did something similar
with a popular FPS (which I legitimately own) on one of my Mac
systems after having left the DVD behind when going to a LAN party.
Addresses removed to protect the innocent^Wguilty, but they took
maybe 15 minutes to acquire:
break *END_OF_CDKEY_CODE_DECRYPTION
run
delete 1
advance *JUST_AFTER_CDKEY_CHECK
set $r3 = 0
detach
At some point every such "locked" computer program has code like this:
> if (program_is_not_authorized()) {
> display_nasty_dialog();
> exit(1);
> }
All it takes for somebody with a debugger is to identify the last
instruction of the "program_is_authorized()" function and change $r3
(or whatever return register your system uses) from a 1 to a 0. The
fact remains that once the software is running on *THEIR* computer
there is nothing you can practically do to forcibly prevent them from
using it in whatever fashion they desire. Typically if you price
your software reasonably people will be willing to pay for multiple
copies but there are no foolproof technical measures to enforce that
they do so.
Cheers,
Kyle Moffett