On 9/25/06, Glenn Fowler gsf at research.att.com wrote:
would '-R $ORIGIN/../lib/ast' work?
FYI, that's how the CSWksh package (out of date now) was done
(actually, it is $ORIGIN/../lib/ksh which resolved to /opt/csw/lib/ksh).
http://blastwave.org/packages/ksh
http://blastwave.org/filesearch/ksh
The updated proposal lists the files that will be in root.
Yes, the root files are only libcmd and libast:
/lib/libcmd*, /lib/{amd64,sparcv9}/libcmd*
/lib/libast*, and /lib/{amd64,sparcv9/libast*.
And please make sure it is lazyloaded (libcmd is pulled in by a large
proportion of applications)
Casper.Dik at Sun.COM wrote:
The updated proposal lists the files that will be in root.
Yes, the root files are only libcmd and libast:
/lib/libcmd*, /lib/{amd64,sparcv9}/libcmd*
/lib/libast*, and /lib/{amd64,sparcv9/libast*.
And please make sure it is lazyloaded (libcmd is pulled in by
Alan Coopersmith wrote:
Roland Mainz wrote:
Well, I offered to fix it. The solution to almost all of the problems is
to rip-out the ksh93d- alpha basis of ksh93 and replace it with a more
recent version (that was at least the cure for HP/UX). And I am still
wondering why it is so
Darren J Moffat wrote:
Roland Mainz wrote:
Darren J Moffat wrote:
[snip]
On the other hand given that you already have to modify the code to have
pfexec used it doesn't seem unreasonable to make it work as the user
expects. I'd be happy to work with you offline to investigate how
Darren J Moffat wrote:
Roland Mainz wrote:
However there are multiple workarounds (already described in other
postings here (e.g. use fully qualified path, an alias to the full path
etc.)) and AFAIK at least the following solutions:
1. pfksh93 checks whether there is a RBAC entry for the
Joseph Kowalski wrote:
From: Roland Mainz roland.mainz at nrubsig.org
...
No argument here, except the IMHO dtksh is more than half-broken. 8^)
Well, I offered to fix it. The solution to almost all of the problems is
to rip-out the ksh93d- alpha basis of ksh93 and replace it with a
Glenn Fowler wrote:
On Mon, 25 Sep 2006 15:41:07 -0400 James Carlson wrote:
April Chin writes:
[snip]
Whatever bit of text documents this path (the original case proposed
Volatile stability for the /usr/ast/bin mechanism, which means it's
a public interface) should note that it may cause
James Carlson wrote:
[snip]
maybe for now pf should trump all builtins but the ones already allowed
whether by /usr/ast/bin or not
That'd be the least problematic answer.
But IMO it is the wrong solution (see my other emails for details, the
builtin thing is something coming from the POSIX
On Wed, 27 Sep 2006 05:00:36 +0200 Roland Mainz wrote:
Glenn Fowler wrote:
ok
I think it would be possible for us to configure a pfksh93 that allows
only a predefined set of builtins (matching those already allowed)
and no runtime builtin additions
I think users should still be allowed
Felix Schulte wrote:
On 9/26/06, Joerg Schilling Joerg.Schilling at fokus.fraunhofer.de wrote:
Darren J Moffat Darren.Moffat at Sun.COM wrote:
April Chin wrote:
An update from the project team on the pfksh93 issue...
Although some ideas on disabling built-ins for pfksh93
has
Casper.Dik at Sun.COM wrote:
The updated proposal lists the files that will be in root.
Yes, the root files are only libcmd and libast:
/lib/libcmd*, /lib/{amd64,sparcv9}/libcmd*
/lib/libast*, and /lib/{amd64,sparcv9/libast*.
And please make sure it is lazyloaded (libcmd is pulled in by
Since dtksh isn't open source (until some group of people
persuade the Open Group folks to Do The Right Thing and
open CDE :-) ), how can non-Sun people work on it, short
of shelling out major $$ for a CDE source license?
This message posted from opensolaris.org
Roland Mainz roland.mainz at nrubsig.org wrote:
From my experience I'd say that the author of a script that explicitly
uses #!/usr/bin/pfksh rather than #!/usr/bin/ksh is expecting a
different behaviour with respect to builtins.
As far as the test suite for ksh93 is concerned I think
Roland Mainz roland.mainz at nrubsig.org wrote:
This issue is not ksh93-specific - it's specific (but not limited to)
almost all POSIX(-like) shells... for example a pfbash would have the
same problem and AFAIK you don't even have a way to turn them off... ;-(
Fortunately nobody likes to make
Roland Mainz roland.mainz at nrubsig.org wrote:
I really wish we could get dtksh fixed... as I said elsewhere this work
would provide very usefull information for creating a Gnome sibling and
even feedback for making adjustments to libshell before making it's API
public. The question is how
Torrey McMahon wrote:
I'm lost as well. Is the issue...
Why is anyone updating tar at all?
Because tar needs to backup your ACLs.
Why did someone put ZFS acl support in tar?
They didn't they put NFSv4/ZFS acl support in to tar.
Why wasn't it documented?
It is documented, very clearly on
.
--
Darren J Moffat
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: def
URL:
http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20060927/96870545/attachment.ksh
login Not a Service - looks like it but isn't
passwd Not a Service
su Not a Service
sys-suspendNot sure on this one, there might be a better RBAC way
Specifically for the first three of these, much of similar configuration
lives
Joseph Kowalski Joseph.Kowalski at eng.sun.com wrote:
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
...
You are not allowed to change the behavior of his program without
an OK from the author of program xxx that is going to replace this
program soon.
That
Joseph Kowalski Joseph.Kowalski at eng.sun.com wrote:
Still, doesn't it seem like having uncovered this issue, that contact
between Joerg and the quite active zfs team be established? I don't
think its my right to had out the appropriate aliases.
Well I did have a face to face discussion
Roland Mainz wrote:
Alan Coopersmith wrote:
Roland Mainz wrote:
Well, I offered to fix it. The solution to almost all of the problems is
to rip-out the ksh93d- alpha basis of ksh93 and replace it with a more
recent version (that was at least the cure for HP/UX). And I am still
wondering why
Darren J Moffat Darren.Moffat at Sun.COM wrote:
Torrey McMahon wrote:
I'm lost as well. Is the issue...
Why is anyone updating tar at all?
Because tar needs to backup your ACLs.
This is no reason for doing it in a nonportable and deprecated way.
Why did someone put ZFS acl support
Darren J Moffat Darren.Moffat at Sun.COM wrote:
Attached is my swag on what is and is not a service, 64% or the 28 files
on the snv_46 system I looked at could in opinion could be stored in SMF.
Add:
cdrecordNot a service
readcd Not a service
cddawav Not a service
Roland Mainz wrote:
I would expect that both shells behave exactly the same way unless there
are RBAC rules active which require a different behaviour.
There aren't RBAC rules but the whole point of RBAC and thus a profile
version of ksh93 is that if the user has an RBAC profile entry for a
Roland Mainz wrote:
Darren J Moffat wrote:
[snip]
I would highly recommend not trying to address pfksh93 as part of this
project but cover it when the project to do ksh93 as /usr/bin/ksh comes
along. This gives you more time to deal with it and work with the
OpenSolaris security community
Roland Mainz wrote:
Joerg Schilling wrote:
James Carlson james.d.carlson at Sun.COM wrote:
It can't be in libcmd, because those external programs themselves will
link to libcmd to get the implementation there. You'd just recurse
forever.
In order for this to work, either (A) all
Nicolas Williams Nicolas.Williams at sun.com wrote:
I don't want to add to the fire, but I think we can SUMMARIZE the
situation for ATT, applications of AST outside ATT or the OS, and Sun
as:
...
b) Solaris has never delivered the AST libcmd before, THEREFORE...
c) ...changing the path of
Roland Mainz wrote:
Glenn Fowler wrote:
On Mon, 25 Sep 2006 15:41:07 -0400 James Carlson wrote:
April Chin writes:
[snip]
Whatever bit of text documents this path (the original case proposed
Volatile stability for the /usr/ast/bin mechanism, which means it's
a public interface) should note
Roland Mainz wrote:
is this a restriction issue? is a user knowingly executing an explicit
builtin
a violation (as in a restricted shell sense)?
It could be. RBAC does have the ability to revoke privileges.
Uhm... could you describe an example ? AFAIK RBAC only grants extended
John Plocher John.Plocher at Sun.COM wrote:
PSARC 2004/503 tar: alter efsize functionality
tar can currently overrun it's efsize variable and
subsequently dump core. See the following bug for
more details:
4977739 *tar* coredumps when backing up files 8 gb
Joerg Schilling wrote:
Darren J Moffat Darren.Moffat at Sun.COM wrote:
Torrey McMahon wrote:
I'm lost as well. Is the issue...
Why is anyone updating tar at all?
Because tar needs to backup your ACLs.
This is no reason for doing it in a nonportable and deprecated way.
Deprecated by
Roland Mainz writes:
James Carlson wrote:
[snip]
maybe for now pf should trump all builtins but the ones already allowed
whether by /usr/ast/bin or not
That'd be the least problematic answer.
But IMO it is the wrong solution (see my other emails for details, the
builtin thing is
Joerg Schilling wrote:
Darren J Moffat Darren.Moffat at Sun.COM wrote:
Joerg Schilling wrote:
Darren J Moffat Darren.Moffat at Sun.COM wrote:
Torrey McMahon wrote:
I'm lost as well. Is the issue...
Why is anyone updating tar at all?
Because tar needs to backup your ACLs.
This is no
Joerg Schilling writes:
It also doesn't mean we can't move on from where we are, providing that
what ever we move to can still read archives created with the existing
code base.
Why did Sun move to somewhere from where it is hard to go to a better and
more standard conforming way
On Wed, 27 Sep 2006 13:19:48 +0100 Darren J Moffat wrote:
It could in theory work but why ? You do realise that pfexec(1) is
setuid root right ?
What is the objection to having pfksh93 use pfexec to execute
/usr/bin/chmod rather than the ksh93 builtin chmod ? If I can
understand that
I did agree (and put it in email) that ksh93 is actually better in this
case since there is a way to turn off the builtins. Where I don't agree
is that the writer of the script should have to know to do that when
ksh93 is operating as pfksh93.
What I was planning to do for pfksh was
On Wed, 27 Sep 2006 14:20:39 +0200 Joerg.Schilling at fokus.fraunhofer.de
(Joerg Schilling) wrote:
From my understanding, the cleanes way would be to out ksh::libcmd into
/usr/lib/ksh/ or /usr/lib/ast/ without merging with sun/att::libcmd.
There is no source issue as you only need to change
Joseph Kowalski wrote:
From: Roland Mainz roland.mainz at nrubsig.org
I really wish we could get dtksh fixed... as I said elsewhere this work
would provide very usefull information for creating a Gnome sibling and
even feedback for making adjustments to libshell before making it's API
public.
David Korn wrote:
I did agree (and put it in email) that ksh93 is actually better in this
case since there is a way to turn off the builtins. Where I don't agree
is that the writer of the script should have to know to do that when
ksh93 is operating as pfksh93.
What I was planning to
On Mon, 25 Sep 2006 13:07:28 -0700 Ed Gould wrote:
other fast-tracks currently active, at the PSARC meeting on Wednesday
(10:00 PDT, 17:00 GMT). John and/or Sherri will send out details on how
to join the meeting for the non-Sun participants.
have the call-in details been posted?
thanks
Joerg Schilling wrote:
What would happen if a similar problem did happen with only Sun emplyees
involved?
They would have been working on the same tar, instead of inventing a new copy,
so they wouldn't have the same problem.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Alan Coopersmith writes:
Joerg Schilling wrote:
What would happen if a similar problem did happen with only Sun emplyees
involved?
They would have been working on the same tar, instead of inventing a new copy,
so they wouldn't have the same problem.
Sun is big enough that it does happen
Joerg Barfurth wrote:
One way to fix this would be to place the ksh93 versions of the builtins
into the file system (e.g. as /usr/ast/bin/chmod) and have pfksh93
pfexec that. Unfortunately that also requires all pertinent profiles to
be updated to specify the /usr/ast/bin/* version as
Joerg Barfurth wrote:
A simpler fix that requires far more work would be to replace all the
/usr/bin tools by AST-based equivalents, reconciling all the
incompatibilities that may still exist on the way. Only then disabling
the builtins actually works as it should.
For chmod that might be
On Wed, 27 Sep 2006 16:50:31 +0100 Darren J Moffat wrote:
Joerg Barfurth wrote:
One way to fix this would be to place the ksh93 versions of the builtins
into the file system (e.g. as /usr/ast/bin/chmod) and have pfksh93
pfexec that. Unfortunately that also requires all pertinent
Date: Wed, 27 Sep 2006 10:56:05 -0400 (EDT)
From: Glenn Fowler gsf at research.att.com
On Mon, 25 Sep 2006 13:07:28 -0700 Ed Gould wrote:
other fast-tracks currently active, at the PSARC meeting on Wednesday
(10:00 PDT, 17:00 GMT). John and/or Sherri will send out details on how
to join the
Glenn Fowler wrote:
On Mon, 25 Sep 2006 13:07:28 -0700 Ed Gould wrote:
other fast-tracks currently active, at the PSARC meeting on Wednesday
(10:00 PDT, 17:00 GMT). John and/or Sherri will send out details on how
to join the meeting for the non-Sun participants.
have the call-in details
On Wed, Sep 27, 2006 at 01:48:27PM +0100, Darren J Moffat wrote:
Joerg Schilling wrote:
Sun used an undocumented, non-portable and deprecated method for
archiving UFS ACLs.
So what ? Sun's tar isn't your tar.
Think interop between tar implementations. If true that we used a
deprecated
Darren J Moffat schrieb:
Roland Mainz wrote:
Joerg Schilling wrote:
If ksh93 likes to provide commands that behave like the builtins, the
only
way I see is that ksh93 checks whether a specfic command needs special
treatement and then calls /usr/bin/pfexec /usr/ast/bin/cmd.
Then the
Darren J Moffat Darren.Moffat at Sun.COM wrote:
Joerg Schilling wrote:
Darren J Moffat Darren.Moffat at Sun.COM wrote:
Torrey McMahon wrote:
I'm lost as well. Is the issue...
Why is anyone updating tar at all?
Because tar needs to backup your ACLs.
This is no reason for doing
===
-- next part --
An HTML attachment was scrubbed...
URL:
http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20060927/d12ce1a2/attachment.html
Alan Coopersmith alan.coopersmith at sun.com wrote:
Joerg Schilling wrote:
What would happen if a similar problem did happen with only Sun emplyees
involved?
They would have been working on the same tar, instead of inventing a new copy,
so they wouldn't have the same problem.
So why did
James Carlson james.d.carlson at sun.com wrote:
Alan Coopersmith writes:
Joerg Schilling wrote:
What would happen if a similar problem did happen with only Sun emplyees
involved?
They would have been working on the same tar, instead of inventing a new
copy,
so they wouldn't
This case was approved during today's PSARC meeting with a contingency
on a case to be submitted that will keep the old Sun libcmd and the new
libcmd separate.
An updated proposal including the changes agreed to during today's
meeting will be posted to the case directory later this week. (I will
From: Alan Coopersmith alan.coopersmith at sun.com
...
You forgot and with access to the source code, which unfortunately reduces
the set of people to very close to zero, since CDE is not part of OpenSolaris.
Opps, that is a thorny little issue, isn't it. 8^)
I'd like to discuss on a
In my last message, I should have said that this case was approved with
a dependency (rather than contingency) on a case to be submitted that
will keep the old Sun libcmd and the new libcmd separate. I apologize
for any confusion this may have caused.
The udpated issues file and proposal are now
In my last message, I should have said that this case was approved with
a dependency (rather than contingency) on a case to be submitted that
will keep the old Sun libcmd and the new libcmd separate. I apologize
for any confusion this may have caused.
Hummm, more like a case
The udpated issues file and proposal are now installed in the cases
materials-final directory. Diffs are also available there showing
differences from the previous version. It may take some time before
these are copied to the external mirror site.
--- proposal.sep26Wed Sep 27 12:47:36
On Wed, Sep 27, 2006 at 02:10:02PM -0700, Gary Winiger wrote:
Four new shared libraries from ATT will be introduced,
-and one Sun private shared library (libcmd) will be appended with new
+and one existing shared library (libcmd) will be appended with new
I don't recall anything
Date: Wed, 27 Sep 2006 14:10:02 -0700 (PDT)
From: Gary Winiger gww at eng.sun.com
To: PSARC-EXT at sac.sfbay.sun.com, don.cragun at Sun.COM
Cc: April.Chin at eng.sun.com, ksh93-integration-discuss at opensolaris.org,
roland.mainz at nrubsig.org
Subject: Re: Korn Shell 93 Integration
There might be a problem if any consumer used a full path for OpenSSL
binary /usr/sfw/bin/openssl or libraries so that's another situation
that will have to be checked with all consumers.
[ my apologies, one additional question ]
Besides the proposed symbolic link for
62 matches
Mail list logo
