API to collect some unique IDs

["Followup-To:" header set to comp.os.linux.security.]

On 2008-02-23, Dirk T. Verbeek <dverbeek@xs4all.nl> wrote:
>
> Having a look in /etc/fstab for the UUID of the hard disk is more unique
> yet it can be spoofed.

Having the UUID listed at all in fstab is not guaranteed. (And IIRC the
UUID is for the given filesystem, not the entire disk.)

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

Keith Keller wrote:

> ["Followup-To:" header set to comp.os.linux.security.]
>
> On 2008-02-23, Dirk T. Verbeek <dverbeek@xs4all.nl> wrote:
>>
>> Having a look in /etc/fstab for the UUID of the hard disk is more unique
>> yet it can be spoofed.
>
> Having the UUID listed at all in fstab is not guaranteed. (And IIRC the
> UUID is for the given filesystem, not the entire disk.)
>
> --keith
>
IMHO, using UUID for internal fixed drives is bullshit. No need for that
crap.

Cheers.

--
The world can't afford the rich.

Q: What OS is built for lusers?
A: Which one requires running lusermgr.msc to create them?

My Killfile List: Frank, dennis@home ... Sorry, won't be able to read your
BS any longer.

Keith Keller schreef:
> ["Followup-To:" header set to comp.os.linux.security.]
>
> On 2008-02-23, Dirk T. Verbeek <dverbeek@xs4all.nl> wrote:
>> Having a look in /etc/fstab for the UUID of the hard disk is more unique
>> yet it can be spoofed.
>
> Having the UUID listed at all in fstab is not guaranteed. (And IIRC the
> UUID is for the given filesystem, not the entire disk.)
>
> --keith
>
I suddenly remember something interresting.
I replaced the 60GB HD from my laptop with a 160GB one and put the old
one in an USB enclosure.
When I hooked it up Linux would not accept it because it had the same
UUID as the new internal HD.
Meaning the UUID for the new disk was during formatting generated using
some inputs of the hardware present resulting in exactly the same number
as the original HD.
In a way this means it would remain the same (uniquely identifying!) for
this particular computer but be different on another.

I'm sure to remember there's some stuff on the net about how the HD UUID
is generated.

Hadron wrote:
> Chris Cox <ccox_nopenotthis@airmail.net> writes:
>
>> Hadron wrote:
>>> Chris Cox <ccox_nopenotthis@airmail.net> writes:
>>>
>>>> Alex wrote:
....snippity...
>> Oddly enough key system processes are running as root on his
>> box by default (believe it or not).
>
> I know. What is your point? Seriously.
>
>> What was your point? Other than trying to pick a fight?
>
> my point was that running it via sudo is running it as root in most
> cases. He wanted a way to access these things NOT as root. No
> fight. Just asking why you answered as you did.

Sigh.... so you believe that nothing runs as root? Of course not.
(do you?) My point is that the OP may have been told
some misinformation about root and possibly nothing about role
based security. That's all.

>
>> I was trying to help.. and you were???
>
> Correcting you.

But you didn't correct anything. You just made ... well...
remarks because you felt like it (I guess).

>
>> Sometimes people don't understand security. They simply
>> need somebody to help them to better understand how things
>> work. If you can't run something in a controlled manner
>> as root.. you've got to simply turn the machine off.
>
> WTF are you talking about?

Root, while often attacked as a weakness in *ix systems, is
also one of its greatest strengths. I merely want to bring
some balance if the OP is fearing a program running as root
since ... like it or not... *ix can't function well without
it. That's all. I'll admit, there's a lot of efforts out
there to minimize root... especially where it's certainly
not required, but we're still a ways away from a totally
rootless system (and arguably such a thing is really not
desirable... even if it is possible).

NoStop wrote:
> Keith Keller wrote:
>
>> ["Followup-To:" header set to comp.os.linux.security.]
>>
>> On 2008-02-23, Dirk T. Verbeek <dverbeek@xs4all.nl> wrote:
>>> Having a look in /etc/fstab for the UUID of the hard disk is more unique
>>> yet it can be spoofed.
>> Having the UUID listed at all in fstab is not guaranteed. (And IIRC the
>> UUID is for the given filesystem, not the entire disk.)
>>
>> --keith
>>
> IMHO, using UUID for internal fixed drives is bullshit. No need for that
> crap.

uuid isn't perfect. It's better when the drive can be identified by
it's model and serial number (by-id)... and most can. But you're right that
even that isn't always what you want to do... but some WILL want it.
So it's there...

It's useful when drives change position due to new controllers coming
online (just one example). Using a more persistent name prevents
the pain of dealing with device renames (e.g. /dev/sda becoming /dev/sdb
all of the sudden). But obviously not perfect in cases were a
drive fails and gets replaced... pros and cons either way....

Chris Cox <ccox_nopenotthis@airmail.net> writes:

> Hadron wrote:
>> Chris Cox <ccox_nopenotthis@airmail.net> writes:
>>
>>> Hadron wrote:
>>>> Chris Cox <ccox_nopenotthis@airmail.net> writes:
>>>>
>>>>> Alex wrote:
> ...snippity...
>>> Oddly enough key system processes are running as root on his
>>> box by default (believe it or not).
>>
>> I know. What is your point? Seriously.
>>
>>> What was your point? Other than trying to pick a fight?
>>
>> my point was that running it via sudo is running it as root in most
>> cases. He wanted a way to access these things NOT as root. No
>> fight. Just asking why you answered as you did.
>
> Sigh.... so you believe that nothing runs as root? Of course not.

Once more : the OP asked how to access certain info WITHOUT THEM RUNNING
AS ROOT. You then told him how to run the programs as root(sudo). What
is so hard for you to understand.

Why you think I do not think certain things run as root is anyones guess
as I certainly never said that and I certainly do not think it.

> (do you?) My point is that the OP may have been told
> some misinformation about root and possibly nothing about role
> based security. That's all.

That might be your point now. It certainly was not earlier.

To try and stop you making a bigger fool of yourself I will quote the
original:

,----
| > Is there any API to collect some unique IDs (such as CPU id,
| > harddisk id, SKU, etc) from the system w/o running the final
| > software as root?
`----

See? He is asking for APIs which DO NOT NEED TO RUN AS ROOT. Get it yet?
By using SUDO he ****IS**** running the final SW as ROOT.

On 2008-02-23, NoStop <nospam@nospam.com> wrote:
> Keith Keller wrote:
>>
>> Having the UUID listed at all in fstab is not guaranteed. (And IIRC the
>> UUID is for the given filesystem, not the entire disk.)
>
> IMHO, using UUID for internal fixed drives is bullshit. No need for that
> crap.

Regardless, it's still available. And as I wrote, it's for filesystems,
not drives.

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

Hadron wrote:
> Chris Cox <ccox_nopenotthis@airmail.net> writes:
>
>
>>Hadron wrote:
>>
>>>Chris Cox <ccox_nopenotthis@airmail.net> writes:
>>>
>>>
>>>>Hadron wrote:
>>>>
>>>>>Chris Cox <ccox_nopenotthis@airmail.net> writes:
>>>>>
>>>>>
>>>>>>Alex wrote:
>>
>>...snippity...
>>
>>>>Oddly enough key system processes are running as root on his
>>>>box by default (believe it or not).
>>>
>>>I know. What is your point? Seriously.
>>>
>>>
>>>>What was your point? Other than trying to pick a fight?
>>>
>>>my point was that running it via sudo is running it as root in most
>>>cases. He wanted a way to access these things NOT as root. No
>>>fight. Just asking why you answered as you did.
>>
>>Sigh.... so you believe that nothing runs as root? Of course not.
>
>
> Once more : the OP asked how to access certain info WITHOUT THEM RUNNING
> AS ROOT. You then told him how to run the programs as root(sudo). What
> is so hard for you to understand.
>
> Why you think I do not think certain things run as root is anyones guess
> as I certainly never said that and I certainly do not think it.
>
>
>>(do you?) My point is that the OP may have been told
>>some misinformation about root and possibly nothing about role
>>based security. That's all.
>
>
> That might be your point now. It certainly was not earlier.
>
> To try and stop you making a bigger fool of yourself I will quote the
> original:
>
> ,----
> | > Is there any API to collect some unique IDs (such as CPU id,
> | > harddisk id, SKU, etc) from the system w/o running the final
> | > software as root?
> `----
>
> See? He is asking for APIs which DO NOT NEED TO RUN AS ROOT. Get it yet?
> By using SUDO he ****IS**** running the final SW as ROOT.

Did anyone notice that:

1. The OP has not taken part of this discussion since
the original question.

2. The OP's question has a strong stink of copy protection,
which the open source community shudders at.

--

Tauno Voipio
tauno voipio (at) iki fi

On Feb 24, 10:14 am, Tauno Voipio <tauno.voi...@INVALIDiki.fi> wrote:

> 2. The OP's question has a strong stink of copy protection,
> which the open source community shudders at.

I wish that were true. The truth is that the open source community
shudders at copy protection for closed source programs (to prevent
copying in violation of the license) but raises a holy stink when
anyone tries to copy open source software in violation of its license.

DS

Hadron wrote:
....
> To try and stop you making a bigger fool of yourself I will quote the
> original:
>
> ,----
> | > Is there any API to collect some unique IDs (such as CPU id,
> | > harddisk id, SKU, etc) from the system w/o running the final
> | > software as root?
> `----
>
> See? He is asking for APIs which DO NOT NEED TO RUN AS ROOT. Get it yet?
> By using SUDO he ****IS**** running the final SW as ROOT.

Oh I get that you want to fight.. and not discuss.. I'm upset
at your general rudeness. That's all. Maybe we'll meet someday.
I'll be the guy on the ground looking for my glasses... you'll
be the guy with some cuts on his fist. :)

To each his own I suppose....