On Wed, 04 Jan 2006 19:29:40 GMT, "Garry Freemyer" <garryfre@pacbell.net> wrote:
>Soapbox=on. Blaming=off.
>
>I found it confusing trying to find the "Userspace" part of udev .71. I
>never did find it, I just installed the source, compiled and installed the
>results. All that is at the link is source code and most everything seems to
>go to a udev-079 directory, I chose the most recent - after backing up the
>system.

That is the userspace, whatever is outside of the kernel

>I'm not complaining, this is probably a task intended for those who are
>experienced, and not for linux newbies or ancient linux rusties like me. I
>had a year of linux experience, but that was a long time ago.

Complain away, I'm with you The udev developers have the attitude this
part of it will be done by the distro. And dismiss properly documenting
the thing -- okay if you run SuSE or Mandrival, not so okay with the
Pipe Smokin' Penguin

>Soapbox mode off.
A valid POV :-)

>Perhaps some kind soul would let ignorant sots like me know what we should
>do with the source code for Udev.

If it worked, you done well, I'm still putting it off

Actually, where to put source code (for anything) has absolutely no
impact on the final result, the install target is vital. Probably
why nobody was telling?

One could argue /usr/src and /usr/local/src are the proper place
for source, but they require root to extract / compile. Not good,
one should not extract source tarballs as root, due to security
issues.

Recent usage examples put source code in the users's account,
and one compiles source as user, switching to root only for the
install, this seems a safer approach: not abuse the root account.

Cheers,
Grant.

On 2006-01-04, Grant <bugsplatter@gmail.com> wrote:
>
> One could argue /usr/src and /usr/local/src are the proper place
> for source, but they require root to extract / compile. Not good,
> one should not extract source tarballs as root, due to security
> issues.

You can eat your cake by providing a place under /usr/local/src for
users to compile, either by chmod 1777 /usr/local/src or, if you want,
creating directories for each user under /usr/local/src. Sometimes this
is more important than you might think: if your home directory is on a
root_squashed NFS share, and the install target writes files in the
source tree (hello blackbox), root's going to have some difficulty
running make install from a user's source tree.

--keith

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

Grant wrote:

> On Wed, 04 Jan 2006 19:29:40 GMT, "Garry Freemyer" <garryfre@pacbell.net>
> wrote:
>>Soapbox=on. Blaming=off.
>>
>>I found it confusing trying to find the "Userspace" part of udev .71. I
>>never did find it, I just installed the source, compiled and installed the
>>results. All that is at the link is source code and most everything seems
>>to go to a udev-079 directory, I chose the most recent - after backing up
>>the system.
>
> That is the userspace, whatever is outside of the kernel
>
>>I'm not complaining, this is probably a task intended for those who are
>>experienced, and not for linux newbies or ancient linux rusties like me. I
>>had a year of linux experience, but that was a long time ago.
>
> Complain away, I'm with you The udev developers have the attitude this
> part of it will be done by the distro. And dismiss properly documenting
> the thing -- okay if you run SuSE or Mandrival, not so okay with the
> Pipe Smokin' Penguin
>
>>Soapbox mode off.
> A valid POV :-)
>
>>Perhaps some kind soul would let ignorant sots like me know what we should
>>do with the source code for Udev.
>
> If it worked, you done well, I'm still putting it off
>
> Actually, where to put source code (for anything) has absolutely no
> impact on the final result, the install target is vital. Probably
> why nobody was telling?
>
> One could argue /usr/src and /usr/local/src are the proper place
> for source, but they require root to extract / compile. Not good,
> one should not extract source tarballs as root, due to security
> issues.
>
> Recent usage examples put source code in the users's account,
> and one compiles source as user, switching to root only for the
> install, this seems a safer approach: not abuse the root account.
>
> Cheers,
> Grant.

Thanks kindly Grant. I had not thought of the security issues of extracting
a tarball as root. I should have realized, that the result might be files
that are owned by root but that normal accounts might not be able to run
them, or maybe the extracting as root might be a risk of replacing files
that might not be good to remove.

Whatever reason, I learned something new. Thanks.

Keith Keller wrote:

> On 2006-01-04, Garry Freemyer <garryfre@pacbell.net> wrote:
>>
>
> [about alt.os.linux]
>

> Who told you this? I hope that's not the impression you've gotten from
> the so-called pack of dogs, because I don't know anyone who is helpful
> in this newsgroup who isn't also willing to admit their errors. (Keep
> in mind that often what I do see is trolls calling on people to admit to
> errors that are only in the minds of said trolls.)
>
> --keith
>

Yeah, my negative experiences with the pack dogs was not here in this forum
at all.

Yes, I see a lot of folks who ask questions on certain IRC help channels,
where it really does seem they don't do research. I kind of get a kick out
of saying "Google This and That, and check the first, third and fifth URL
you get. Hehe.

Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> trolled:
> On 2006-01-04, Grant <bugsplatter@gmail.com> wrote:
> >
> > One could argue /usr/src and /usr/local/src are the proper place
> > for source, but they require root to extract / compile. Not good,
> > one should not extract source tarballs as root, due to security
> > issues.

> You can eat your cake by providing a place under /usr/local/src for
> users to compile, either by chmod 1777 /usr/local/src or, if you want,
> creating directories for each user under /usr/local/src. Sometimes this

Anal-retention. There is no reason not to unpack a tarball in a
root dir, especially if you get the tarball from a trusted src.

> is more important than you might think: if your home directory is on a
> root_squashed NFS share, and the install target writes files in the
> source tree (hello blackbox), root's going to have some difficulty
> running make install from a user's source tree.


Nonsense.

cordially, as always,

rm

Garry Freemyer <garryfre@pacbell.net.nopsam> trolled:

> > Recent usage examples put source code in the users's account,
> > and one compiles source as user, switching to root only for the
> > install, this seems a safer approach: not abuse the root account.
> >
> > Cheers,
> > Grant.

> Thanks kindly Grant. I had not thought of the security issues of extracting
> a tarball as root. I should have realized, that the result might be files
> that are owned by root but that normal accounts might not be able to run
> them, or maybe the extracting as root might be a risk of replacing files
> that might not be good to remove.

> Whatever reason, I learned something new. Thanks.

Sorry, but all you learned was anal-retentive nonsense. It should
be obvious by now that a large percentage of linux users, especially
slackware linux users, are hopeless anals. (Just think of the white
guy smoking a pipe) Grant, here, is one of them.

Of course, you might be anal as well, and that may be the reason you
are here. If so, you did come to the right place.

Now you really have learned something.

cordially, as always,

rm

On Wed, 4 Jan 2006 13:05:09 -0800, Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:

>On 2006-01-04, Grant <bugsplatter@gmail.com> wrote:
>>
>> One could argue /usr/src and /usr/local/src are the proper place
s/could/might/ ??
>> for source, but they require root to extract / compile. Not good,
>> one should not extract source tarballs as root, due to security
>> issues.
>
>You can eat your cake by providing a place under /usr/local/src for
>users to compile, either by chmod 1777 /usr/local/src or, if you want,

Sure, up until six months ago I was compiling kernels under /usr/src,
some as user, sometimes as root... Then I reviewed that and decided
to change, no more kernel source trees with unknown parentage

>creating directories for each user under /usr/local/src. Sometimes this
>is more important than you might think: if your home directory is on a
>root_squashed NFS share, and the install target writes files in the
>source tree (hello blackbox), root's going to have some difficulty
>running make install from a user's source tree.

That's a different scenario, yes? If your home directory is root
squashed its probably 'cos you don't have admin rights to install
system software, no?

There's guidelines and there's reality with the flexibility with
enough rope

For a hosted compile I have a target box exporting / with root
access, works for me, probably scare a 'normal' sys-admin )

But then, hostile users here is me in a bad mood o_O

Grant.

On 2006-01-04, Grant <bugsplatter@gmail.com> wrote:
> On Wed, 4 Jan 2006 13:05:09 -0800, Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
>
>>creating directories for each user under /usr/local/src. Sometimes this
>>is more important than you might think: if your home directory is on a
>>root_squashed NFS share, and the install target writes files in the
>>source tree (hello blackbox), root's going to have some difficulty
>>running make install from a user's source tree.
>
> That's a different scenario, yes? If your home directory is root
> squashed its probably 'cos you don't have admin rights to install
> system software, no?

Not necessarily. Conceivably, I could have the root password for my
desktop so I can install system software, but the NFS share could be
root-squashed so that I can't b0rk other people's files. (Of course, I
can do it anyway by su to root, then su to each user.) Or I could just
have root_squash on as another layer of defense (a thin one, admittedly,
but any port in a storm, right?). Or maybe I want to protect my NFS
share from commands for which users have sudo access, in the unlikely
event that I've inadvertently given them sudo that drops into a shell or
editor. (Maybe users can sudo make install? I never tried that....)

--keith

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

On Wed, 4 Jan 2006 14:39:06 -0800, Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:

>On 2006-01-04, Grant <bugsplatter@gmail.com> wrote:
>> On Wed, 4 Jan 2006 13:05:09 -0800, Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
>>
>>>creating directories for each user under /usr/local/src. Sometimes this
>>>is more important than you might think: if your home directory is on a
>>>root_squashed NFS share, and the install target writes files in the
>>>source tree (hello blackbox), root's going to have some difficulty
>>>running make install from a user's source tree.
>>
>> That's a different scenario, yes? If your home directory is root
>> squashed its probably 'cos you don't have admin rights to install
>> system software, no?
>
>Not necessarily. Conceivably, I could have the root password for my
>desktop so I can install system software, but the NFS share could be
>root-squashed so that I can't b0rk other people's files. (Of course, I
>can do it anyway by su to root, then su to each user.)

Yeah but then you really are trying, its the inadvertent breakages
catch us out. Like cleaning out /boot and doing an rm * in there
by accident
> Or I could just
>have root_squash on as another layer of defense (a thin one, admittedly,
>but any port in a storm, right?). Or maybe I want to protect my NFS
>share from commands for which users have sudo access, in the unlikely
>event that I've inadvertently given them sudo that drops into a shell or
>editor. (Maybe users can sudo make install? I never tried that....)

I don't run sudo, su + root password makes me pause a little, realise
I'm crossing into system software territory, if you like. And once
root I can kill the machine just as dead with finger trouble

Anyways, I'm not discounting your argument, so many ways to shoot
one's foot, so many local variations in requirements.

Grant.

"Realto Margarino" <rm@biteme.org> wrote in message
news:meXuf.2059$H37.318972@news20.bellglobal.com.. .
> Garry Freemyer <garryfre@pacbell.net.nopsam> trolled:
>
>> > Recent usage examples put source code in the users's account,
>> > and one compiles source as user, switching to root only for the
>> > install, this seems a safer approach: not abuse the root account.
>> >
>> > Cheers,
>> > Grant.
>
>> Thanks kindly Grant. I had not thought of the security issues of
>> extracting
>> a tarball as root. I should have realized, that the result might be files
>> that are owned by root but that normal accounts might not be able to run
>> them, or maybe the extracting as root might be a risk of replacing files
>> that might not be good to remove.
>
>> Whatever reason, I learned something new. Thanks.
>
> Sorry, but all you learned was anal-retentive nonsense. It should
> be obvious by now that a large percentage of linux users, especially
> slackware linux users, are hopeless anals. (Just think of the white
> guy smoking a pipe) Grant, here, is one of them.
>
> Of course, you might be anal as well, and that may be the reason you
> are here. If so, you did come to the right place.
>
> Now you really have learned something.
>
> cordially, as always,
>
> rm

When ever I hear the phrase anal retentive, I think of the medial term for
this condition - CraneoRectalitis, or OpticRectalitis, a crappy outlook in
life. Yep, I know it's an old joke but still funny to me.

I don't know if I'm anal, all that matter to me is if we get a giggle out of
things once and awhile.