Jack Woehr wrote:
There are any number of thousands of pieces on the web about this,
but the real problem with setuid is that it is a hinged chopstick.
A command that you execute because you can is one security risk.
You fix that by auditing the code and installing the executable such
that only
Shane Ginnane wrote:
You are quite right John there are problems with the CDDL.
Linus is dead against this - end of discussion I would have thought. And
considering his rants re ext4 recently, who'd be game to attempt to merge
ZFS even if it was possible :-)
And so we _really_ need yet
Hi ,
Do you have console access to your linux box ?
If you have look at the /sys/class/net to discover if you have a the device
properly configured at your system . You could also look at the
/sys/bus/ccwgroup/drivers/qeth to see if your channel addres was identified
by linux .
If a ls at /*sys*/
Mark,
I haven't specifically worked on a Hipersocket in SLES10 yet, the few
machines I have that utilize them are not yet upgraded from SLES9->10
yet. BUT I have had the exact same problem as you with regular QETH
devices. It seems that YaST doesn't always properly configure and then
hwup the de
The ccwchanids need to be filled in. Sles9 would autosense the three devices
associated with the group device, sles10 does not.
You actually have to put in the 0.0704,0.0.0705,0.0.0706 between the quotes.
Ron
Sent via BlackBerry by AT&T
-Original Message-
From: "roger.ship...@daimler.
Thank you!
2009/3/31
> Look at this manual..don't worry about the title..It has a great write up
> and directions on HIPER.
> We just went from SLES9 th 10 and I use the instructions:
>
> http://www.redbooks.ibm.com/redpieces/pdfs/sg246847.pdf
>
>
> example:
> echo 0.0.b500,0.0.b501,0.0.b502 >
>>> On 3/31/2009 at 3:42 PM, Mark Pace wrote:
> Not having any luck with Hipersockets in SLES10, working great in SLES9
> Does this look correct for a Hipersocket device in SLES10?
No. There was a regression (I can't quite call it a bug) in SP2 where going in
to YaST to configure an interface
Look at this manual..don't worry about the title..It has a great write up
and directions on HIPER.
We just went from SLES9 th 10 and I use the instructions:
http://www.redbooks.ibm.com/redpieces/pdfs/sg246847.pdf
example:
echo 0.0.b500,0.0.b501,0.0.b502 > /sys/bus/ccwgroup/drivers/qeth/group
Not having any luck with Hipersockets in SLES10, working great in SLES9
Does this look correct for a Hipersocket device in SLES10?
sles002:/etc/sysconfig/hardware # cat hwcfg-qeth-bus-ccw-0.0.0704
CCW_CHAN_IDS=''
CCW_CHAN_MODE=''
CCW_CHAN_NUM='3'
LCS_LANCMD_TIMEOUT=''
MODULE=''
MODULE_OPTIONS=''
Q
I don't see much of a difference, that is, other than the wording.
>From the Oracle SIG:
Oracle on Linux on System z Workshop:
In conjunction with the Oracle zSeries SIG 2009 Conference, IBM is
hosting a special 'no-charge' workshop for conference attendees who are
considering consolidating and m
>Are Hipersocket devices supposed to show up in Yast as 3 different
devices,
>where an OSA adapter shows up as 1?SLES10 SP2
>IBM OSA Express Network card (0.0.1d00)│
>IBM Hipersocket (0.0.0704) │Not configured
> │
>IBM Hipersocket (0.0.0705) │Not configured
> │
>IBM Hipe
Are Hipersocket devices supposed to show up in Yast as 3 different devices,
where an OSA adapter shows up as 1?SLES10 SP2
IBM OSA Express Network card (0.0.1d00)│
IBM Hipersocket (0.0.0704) │Not configured
│
IBM Hipersocket (0.0.0705) │Not configured
│
IBM Hipersocket (
There are any number of thousands of pieces on the web about this,
but the real problem with setuid is that it is a hinged chopstick.
A command that you execute because you can is one security risk.
You fix that by auditing the code and installing the executable such
that only root almighty can w
Erik N Johnson wrote:
This is generally considered highly insecure. The usual caveat about
running userland apps as root.
In fact, the generally accepted practice amongst most Linux admins is:
ALWAYS issue administrative commands using sudo.
This and Everything Erik says is True. I posted in
I think if you look at the agenda of both, there is quite a difference.
Tom Duerbusch wrote:
This SIG seems to be the same education available, free, at other
locations also.
See the announcement at the bottom of this email:
Tom Duerbusch
THD Consulting
Barton Robinson 3/30/2009 7:20
PM >>
This is generally considered highly insecure. The usual caveat about
running userland apps as root.
In fact, the generally accepted practice amongst most Linux admins is:
ALWAYS issue administrative commands using sudo. NEVER log in
remotely as root. ONLY log in as root w/ physical access, and
I tend to agree that sudo is a much better way of accomplishing this,
you can embed sudo in scripts as long as the script is called
interactively. Thus it would be very simple to get some info about
the process in question (specifically uid) from either the ps command
or the /proc directory (every
Mark Post wrote:
Oh, minor terminological pedanticism: when the set is on the group we call
it setgid to differentiate from setuid.
Hardly minor, since the behavior it enables is completely different from setuid.
True, but I was trying not to be /breathless/ about it, just hinting to
the p
>>> On 3/31/2009 at 11:48 AM, Jack Woehr wrote:
-snip-
> Oh, minor terminological pedanticism: when the set is on the group we call
> it setgid to differentiate from setuid.
Hardly minor, since the behavior it enables is completely different from setuid.
Mark Post
This SIG seems to be the same education available, free, at other
locations also.
See the announcement at the bottom of this email:
Tom Duerbusch
THD Consulting
>>> Barton Robinson 3/30/2009 7:20
PM >>>
Any one that is interested in running Oracle on "Z", the conference
will
be held in 3 weeks:
CHAPLIN, JAMES (CTR) wrote:
-r--rwsr--+ 1 user group 500 Jan 21 16:23 stopServer.sh
The setuid is set on group level.
It has to be setuid to root because only root can send signal
to other user's processes. So it has to be owned by root and
should be something like -r-sr-x---
Oh, minor termi
Re: how to cause a Java app to shutdown IF you have the authority to send it
a signal:
Java JVMs on *nix generally will respond to SIGINT (2) or SIGTERM(15) by
exiting "normally".
An application an register a "shutdownhook" and run some code to clean up if
necessary.
Here's a link:
http://www.ib
-r--rwsr--+ 1 user group 500 Jan 21 16:23 stopServer.sh
The setuid is set on group level.
Removed the user execute perms as shown above, and script failed to
"kill -p pid", got permission denied message still.
Did a chmod 2474 stopServer.sh to set the bits, is this correct in what
you are suggest
On Tuesday 31 March 2009 09:43, CHAPLIN, JAMES (CTR) wrote:
>Our programmers have been creating java based applications that they
>start and stop using simple scripts. The start script call java to start
>the program; however the stop script issues a simple kill command
>against the PID.
>
>Our pro
>> Our programmers have been creating java based applications that they
>> start and stop using simple scripts. The start script call java to start
>> the program; however the stop script issues a simple kill command
>> against the PID.
Ugh. Wrong, wrong, wrong, unless they have set up their app
CHAPLIN, JAMES (CTR) wrote:
We want anyone in the group level to be able to also issue
the kill command (in the script). Is there a way to allow users in a
group to kill each other's started processes.
You can have a script or program
* with the setuid bit set
* with the write permissio
IMO - the java app should provide a way to tell it to exit gracefully - and
the stop script would exercise that.
Scott
On Tue, Mar 31, 2009 at 7:43 AM, CHAPLIN, JAMES (CTR) <
james.chap...@associates.dhs.gov> wrote:
> Our programmers have been creating java based applications that they
> start a
Our programmers have been creating java based applications that they
start and stop using simple scripts. The start script call java to start
the program; however the stop script issues a simple kill command
against the PID.
Our problem if User A start the program, only User A can kill it (except
28 matches
Mail list logo