On 03/18/10 09:54 PM, Sebastien Roy wrote:
Norm,
On 03/18/10 07:57 PM, Norm Jacobs wrote:
It's not that I don't think that the ksh93 built-ins have a place and
that they couldn't be a perfectly reasonable default for most people. In
some cases, they seem to provide something that is sorely
On 03/19/10 07:19 AM, Sebastien Roy wrote:
Norm,
On 03/19/10 04:34 AM, Norm Jacobs wrote:
I think that in part, I misread this:
Interface Stability Description
- - ---
ksh93 '/usr/gnu/bin/basename' built in Uncommitted basename utility
with GNU extensions
I'm not a member of PSARC and can't actually vote here, but I would have
to give this case a -1.
It's not that I don't think that the ksh93 built-ins have a place and
that they couldn't be a perfectly reasonable default for most people.
In some cases, they seem to provide something that is
Raj Prakash wrote:
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
GCC4: The GNU Compiler Collection 4.X
4. Technical Description:
4.1. Details:
Commands will be installed in /usr/bin with versioned suffixes,
George Vasick wrote:
Norm Jacobs wrote:
Raj Prakash wrote:
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
GCC4: The GNU Compiler Collection 4.X
4. Technical Description:
4.1. Details:
Commands will be installed
Milan Jurik wrote:
Hi,
Norm Jacobs p??e v ?t 29. 09. 2009 v 13:51 -0500:
Garrett D'Amore wrote:
[...]
2) Are there any plans to enhance CUPS to distributed network printer
configuration via NIS? Or is there a replacement for this service
already present? (I guess
Garrett D'Amore wrote:
+1. I think this will be a big help.
I've a few questions (which probably count as not this case) though:
1) Upgrades -- will upgrades (or pkg image-update) switch the service,
or leave the existing setting?
Venky can correct me if I am wrong here, but I believe that
Ok, I get the 64-bit libraries, but I have to ask about the 64 bit
commands in /usr/bin/... What do they buy us? Are they necessary?
Shouldn't you be isaexec()ing here? Is there a 64-bit pkgconfig file?
-Norm
Brian Cameron wrote:
5. Interface changes since LSARC 2008/706:
I. Szczesniak wrote:
On 5/26/09, James Carlson James.D.Carlson at sun.com wrote:
Rich Burridge writes:
Perl 5.10.x is binary-incompatible with 5.8.x, so it will be
necessary
to declare 5.8.x EOF in OpenSolaris, and remove it in a later
version.
A
Jim Walker wrote:
For LSARC, PSARC and the opinion writer(s) to consider
Michael Kearney wrote:
1. Lloyd, I like the idea of your annotation but have a couple of
concerns.
- Would teams be expected to update third party, open source jar
files with the annotation?
- Would
Python 3.0 has been ARC'd, but hasn't delivered yet. You can ARC the
python 3.0 pywbem interfaces now, but presumably you want python 3.0 to
deliver them.
-Norm
Vivek Titarmare wrote:
It's Ok. I will re-add the 3.0 version to the prototype_com
Best Regards,
~Vivek R. Titarmare
Casper.Dik at sun.com wrote:
If a user has run su in one terminal, any other terminal can be used to
control su; this includes any form of malware. I wdon't want to change
it because it still allows privilege escalation.
Not really. If the user has escalated privilege in one
Gary Winiger wrote:
IMO, this case should be withdrawn and the bug should be fixed.
If I'm wrong about the bug, then the case should be reintroduced
with rational as to why there isn't a bug and what the policy really
should be for TIOCSTI.
I'll give the project team
Casper.Dik at sun.com wrote:
Norm,
4) Conclusion on privs/uids.
Nit: the exec_attr entry s/suser/solaris/
Is it really the euid that matters, or is it that euid=0 gives
privs=all? I don't know how to answer the tiocsti question.
I'm not sure that's
Casper.Dik at Sun.COM wrote:
Gary Winiger wrote:
IMO, this case should be withdrawn and the bug should be fixed.
If I'm wrong about the bug, then the case should be reintroduced
with rational as to why there isn't a bug and what the policy really
should be for TIOCSTI.
Gary Winiger wrote:
/etc/security/prof_attr:
Parallel Console Access:::Connect to remote consoles with pconsole:
To whom/how is this Rights Profile granted?
Also note that a help file needs to come with the addition of
a Rights Profile. See:
Nicolas Williams wrote:
On Mon, May 04, 2009 at 12:34:29PM -0500, Norm Jacobs wrote:
James Carlson wrote:
Norm Jacobs writes:
TIOCSTI appears to require elevated privilege. streamio.c appears to
do the auth checking in the kernel using secpolicy_sti(), which equates
James Carlson wrote:
Norm Jacobs writes:
TIOCSTI appears to require elevated privilege. streamio.c appears to
do the auth checking in the kernel using secpolicy_sti(), which equates
If you issue it on the controlling tty for this process and you have
at least read access
Joerg Schilling wrote:
Garrett D'Amore gdamore at sun.com wrote:
My only small concern with this project is the name bsh. ISTR being
on other systems where bsh meant the Bourne Shell. It seems like
beansh might be a better name here to avoid possible confusion. But
if this is
Joerg Schilling wrote:
Norm Jacobs Norm.Jacobs at sun.com wrote:
Joerg Schilling wrote:
Garrett D'Amore gdamore at sun.com wrote:
My only small concern with this project is the name bsh. ISTR being
on other systems where bsh meant the Bourne Shell. It seems like
Danek Duvall wrote:
On Tue, Apr 14, 2009 at 02:19:34AM -0700, James Walker wrote:
/usr/lib/cups/backend/halVolatileCUPS backend
/usr/lib/hal/hal_lpadmin VolatileHAL hot-plug action
Aren't these really Private?
Danek
Yes, they
Darren J Moffat wrote:
Brian Utterback wrote:
James Carlson wrote:
Creating a separate tiny root package allows the owner of a system
with writable RBAC files but without a writable '/usr' to install the
necessary bits to make this feature work. If it's done as you're
suggesting, as a
Brian Utterback wrote:
Norm Jacobs wrote:
orphaning that may occur. There are several components in SFW that
already deliver root packages with RBAC entries.
But only one (SUNWmkcdr) delivers nothing else. What do you see as the
problem here?
In this particular case, I doubt that you
I care enough to want to see the root package added to this case.
-Norm
Brian Utterback wrote:
The case was approved with only a single package and separate
integration into ON. Does anybody care enough to want to re-open the
case, or are we really just talking about getting IPS
While I agree with you in principle, we should be building all of
Solaris with Studio, there are cases where using Studio is not really
worth the effort. There are several open source components out there
that seem to make heavy use of GCC extensions or what I more lovingly
like to think of
I am sending this out be cause Wendy is out sick. Please let me know if there
are any issues by Thursday May 8th.
-Norm
I am creating this self-review on behalf of Norm Jacobs. Though there are not
current plans to backport this technology, it is for patch/micro release binding
Norm Jacobs wrote:
In my original materials for PSARC/2008/130 CUPS 1.3.6 I designated an
interface stability of Volatile for
the libcups and libcupsimage interfaces. I don't believe that we are
likely to see incompatible change in these interfaces from the open
source project
Garrett D'Amore wrote:
Norm Jacobs wrote:
Norm Jacobs wrote:
In my original materials for PSARC/2008/130 CUPS 1.3.6 I designated
an interface stability of Volatile for
the libcups and libcupsimage interfaces. I don't believe that we
are likely to see incompatible change
Garrett D'Amore wrote:
Norm Jacobs wrote:
Garrett D'Amore wrote:
Norm Jacobs wrote:
Norm Jacobs wrote:
In my original materials for PSARC/2008/130 CUPS 1.3.6 I
designated an interface stability of Volatile for
the libcups and libcupsimage interfaces. I don't believe that we
are likely
James Carlson wrote:
Norm Jacobs writes:
to accommodate the realities of today. Given what I am trying to
acheive, perhaps Uncommitted Obsolete would be more appropriate.
This is just a minor nit, but I'd suggest using Obsolete Committed.
Obsolete Uncommitted is possible
In my original materials for PSARC/2008/130 CUPS 1.3.6 I designated an
interface stability of Volatile for
the libcups and libcupsimage interfaces. I don't believe that we are
likely to see incompatible change in these interfaces from the open
source project and there are potentially a number
Actually, we have a cooperative process for dealing with this kind of
thing. It's call ARCing.
Joerg Schilling wrote:
Casper.Dik at Sun.COM wrote:
For this reason, the compare from imagemagick either needs to be renamed
or it needs to be put into a different directory.
Your
Joerg Schilling wrote:
Norm Jacobs Norm.Jacobs at Sun.COM wrote:
Your argument there is with the open source community. It's the
ImageMagick open source project that chose the name compare for their
program. Yes, we did choose to place it in /usr/bin along with the rest
Artem Kachitchkine wrote:
Nicolas Williams wrote:
On Tue, Sep 04, 2007 at 12:50:43PM -0700, Danek Duvall wrote:
On Tue, Sep 04, 2007 at 02:12:18PM -0500, Norm Jacobs wrote:
I can envision a time when we might want to update it to recognize
more
device types. If we were to break this down
Danek Duvall wrote:
On Wed, Aug 29, 2007 at 04:19:46PM -0500, Norm Jacobs wrote:
The hald-addon-network-discovery module could be used to detect other types
of network attached devices, like scanners or storage, but it is
specifically looking for printers. The hald-probe-network
Danek Duvall wrote:
On Tue, Sep 04, 2007 at 02:12:18PM -0500, Norm Jacobs wrote:
Danek Duvall wrote:
Okay. Isn't it strange, then, that you're assigning the Printer
Management profile to the SMF service instances when those instances
could be discovering things other than Printers
Bill Sommerfeld wrote:
On Thu, 2007-08-30 at 10:34 +0100, Darren J Moffat wrote:
I'm not sure that secure-by-default does require that this be off. As I
understand this case it is egress probing not a daemon listening of
ingress requests.
So we're ok at the transport layer, but
Erik Nordmark wrote:
Artem Kachitchkine wrote:
An example network attached printer entry looks remarkably like this:
udi = '/org/freedesktop/Hal/devices/network_attached/192_168_0_15'
What would happen if a user has a printer at work at (private) IP
address 192.168.0.15, and has a
Gary Winiger wrote
At least some of what people send to printers tends to be sensitive.
And for TX, I'd hope this is covered. How does this project relate
to TX? Does HAL run in each of the labeled zones and pick up
network printers at that label?
Artem can
John Plocher wrote:
Darren J Moffat wrote:
I'm not sure that secure-by-default does require that this be off.
As I understand this case it is egress probing not a daemon listening
of ingress requests.
I defer to your expertise :-)
My concern was one of 2nd-order exposure:
I (the bad
James Carlson wrote:
Norm Jacobs writes:
1. It doesn't send out a response to any queries on the network.
Just being open is enough. The fact that it's open is easily
detectable, because the system won't send back an ICMP Destination
Unreachable / Port Unreachable when a packet
James Carlson wrote:
Artem Kachitchkine writes:
In order to better support these devices, this case seeks to extend the
current HAL offering by adding a network attached device discovery
service addon module and a probe module to probe network attached
printers for identifying data.
Danek Duvall wrote:
Network Device Discovery
Actual network device discovery will be handled by the HAL addon module
named hald-addon-network-discovery. This module will be tied into the
HAL device tree at /org/freedesktop/hal/devices/network_attached by
Danek Duvall wrote:
On Wed, Aug 29, 2007 at 06:34:37PM -0400, Bill Sommerfeld wrote:
But I think we could do better than to force users to pick printers by
mac address or ip address.
That's not what this is about -- I think that as long as a human-readable
name is available, that
John Plocher wrote:
Danek Duvall wrote:
in our environment, would all 5000
printers show up, or some subset of those?
I assume that, like today, if the user has a ~/.printers file,
its all: entry will be used. If this is done naively, it could
completely hide any auto-discovered
Danek Duvall wrote:
On Wed, Aug 29, 2007 at 06:03:40PM -0500, Norm Jacobs wrote:
The SWAN's 5000 printers that you are referring to are not physical
printers, but queues advertised in the network name services.
But presumably a large number of those printers so represented
46 matches
Mail list logo
