Re: [sher...@sac.sfbay.sun.com: Intel AVX Support [PSARC/2010/311 FastTrack timeout 08/11/2010]]
I've read over this case for a second time and with the suggestion from Jim Carlson on mdb output I have no other issues. So it gets my +1. A well written case that answered all my questions - even if I did have to wait until 4.1.7 and 4.11 to get the questions I cared about most answered :-) -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC 2010/312 Link-editor guidance
Well presented rationale and the interface looks good. This gets my +1 as specified. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: NFS Instances [PSARC/2010/280 FastTrack timeout 07/29/2010]
On 28/07/2010 04:58, Gary Winiger wrote: This seems to me to be an incompatible change that doesn't need to be made. If before this project, sys_config was the privilege that allowed sharing, it should continue to allow sharing. In addition sys_share should allow sharing. I believe it was already determined that sys_config cannot/should not/must not be granted to a NGZ. While it is an incompatible change I believe it is perfectly acceptable because the provider RBAC profiles we provide for sharing are still legacy suser with uid=0 (ie all privs). More importantly we don't document libshare or sharefs at all and the share_nfs(1M), share(1M), sharemgr(1M) man pages (which are the only supported interfaces for sharing filesystems) don't document which privileges are required either. It is sharefs that makes the privilege check against sys_config today. So really this is currently an implementation detail of libshare and sharefs today. If the project wishes to make this incompatible change, please justify it (and perhaps how it would be mitigated for all existing users of sys_config to share). The definition of sys_config provided by 'ppriv -lv sys_config' or the privileges(5) man page don't document that sys_config is checked for sharing NFS (or CIFS) filesystems. There is a change in which privilege is checked but I think it is perfectly acceptable and shouldn't be visible as an incompatible change except to those people who have reverse engineered what privileges they think share_nfs(1M) needs to have. So the case gets my +1 as specified. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010]
A great set of additions none of which seem controversial to me and many of which I've lacked when compiling random bits of FOSS, so it gets my +1 as specified. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: zonestat [PSARC/2010/291 FastTrack timeout 08/02/2010]
DJM-1 zonestatd What is the SMF method script used to start zonestatd ? ie what uid/gid and privileges does it run with ? What is the RBAC authorisation used for managing the SMF service state and the config value changes ? DJM-2 what method is used to ensure that zonestatd doesn't return information about other ngz's when zonestat is run from an ngz ? DJM-3 Can zonestat(1) run as an normal user (ie with no privileges other than basic and no additional RBAC authorisations other than those granted by Basic Solaris User) ? If so is there any information that user can get that they can't through existing commands ? DJM-4 I assume this works in a TX zone configuration DJM-5 I don't see how the FMRI can be Consolidation Private if the config/sample_internal is Committed. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: zonestat [PSARC/2010/291 FastTrack timeout 08/02/2010]
On 27/07/2010 17:47, Steve Lawrence wrote: It runs as uid/gid 0. I'll work out which privileges are needed so I can drop the rest. daemon/daemon with privileges would be better. If zonestatd is the method started by SMF you may also be able to remove the basic proc_exec privilege if zonestatd as well. I just reviewed the privileges. zonestatd does a zone_enter() to fetch resource control info, which requires all privileges. I would need to implement a getrctl_byid(2) system call to avoid this. The current getrctl(2) system call uses the context of the caller. Okay, if this was a full case I would be suggesting TCA maybe TCR to implement getrctl_byid(2) so that zonestatd didn't have to zone_enter() and thus need all privilege. As this is a fast-track I'll suggest the project team log a CR for getrctl_byid(2) if it doesn't already exist, and log a bug for zonestatd to switch to using that and then no longer run with all privilege (basically the equivalent of a TCA without an ARC opinion document). -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: NFS Instances [PSARC/2010/280 FastTrack timeout 07/29/2010]
On 22/07/2010 17:52, Nicolas Williams wrote: On Thu, Jul 22, 2010 at 11:34:44AM -0500, Robert Gordon wrote: There isn't really any current behavior with respect to sharing in a zone :) I understand what you are saying and the zone boot restriction can be removed, it doesn't effect the proposed new interfaces. My concern is inadvertent zone data leakage ... I think there is a compatibility issue. Prior to this project the g-z could share a zone's resources, now either, but not both of the g-z and And TX actually depends on that behaviour today, on the other hand once we do have NFS servers within a zone then TX could migrate to using that instead (because that is what it is currently providing the illusion of anyway). -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: NFS Instances [PSARC/2010/280 FastTrack timeout 07/29/2010]
I'm slightly confused by the case title and content. The title implies that this case delivers NFS instances, yet the case content doesn't seem to be enough for that and is more a dependent change to support NFS instances. Is this case the whole NFS instances case ? PRIV_SYS_SHARE can be assigned to a zone, and it is enabled by default for root users in both global and non-global zones. It can also be assigned to Non-privileged users. As an aside a nit on terminology: Privileges are not assigned to users, this is a common misunderstanding of RBAC. Privileges are assigned to processes, usually via an RBAC rights profile which maybe assigned to a user or role. The confusion comes from the fact that defaultprivs is allowed to be set in user_attr(4), what this is really doing is assigning that set of privileges to the users initial program as started by the login program (it is really pam_unix_cred that does this). In generally we don't recommend privileges are assigned to the users initial program in user_attr(4) - one useful common exception to that is the dtrace privileges. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: EOF and removal of installgrub(1m) floppy support [PSARC/2010/271 fasttrack timeout 07/23/2010]
I see no issues with this so it gets my +1. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
PSARC/2009/430 Default system CA (X.509) Certificates [ pkg(5) name update ]
After some discussion at RTI time the package name settled on based on using preexisting hierarchies and getting as close as possible a name match to OEL/RedHat is pkg:/crypto/ca-certificates. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/165 - OpenSolaris Text Installer email vote...
I vote to approve (I wasn't present at the meeting but I have reviewed the materials and opinion). -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: fmd for non-global Solaris zones [PSARC/2010/225 FastTrack timeout 06/25/2010]
On 21/06/2010 16:48, Michael Kearney wrote: In fmadm.1m and fmstat.1m: SYS_CONFIG is a lower priv than SYS_ADMIN or a better fit? lower priv doesn't make sense. Non global zones can't ever have sys_config. So sys_admin is a better fit. Ideally this shouldn't be a privilege check at all but an authorisation based check, however I'm not going to suggest burdening this case with fixing the choices of the past. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/165 - OpenSolaris Text Installer email vote...
On 18/06/2010 16:08, John Fischer wrote: 4.4 User Installed as Primary Administrator The initial user installed by the Caiman installers have been given the Primary Administrator role. The committee pointed out that this role is going away. The issue was discussed in the Solaris Modernization case (PSARC/2010/067). In that case the project team agreed to modify the installers to: Primary Administrator is a Rights Profile not a Role. The distinction is very important. It is the fact that the profile is assigned directly to a user rather than a role what was the whole problem. Also Primary Administrator as a Rights Profile is not planned to go away. The advice of the security team was not to assign Primary Administrator to the initial user directly. The main reason this was done early on in the Caiman GUI installer was because other technology like the RBAC Console User profile wasn't available and neither was sudo. 1. remove the root password prompt 2. require an initial user login name and password 3. set the root password to the initial user password 4. the root is type=role 5. the initial user is granted the root role (type=normal;roles=root) 6. the initial user is put in /etc/sudoers -- presumable with all commands 7. the initial use is no longer granted the Primary Administrator Rights Profile initial user 8. the password hash algorithm is sha256 9. the root account password is installed as expired (passwd -f). sp_lstchg == 0 username:password:lastchg:min:max:warn:inactive:expire:flag sp_namp:sp_pwdp:sp_lstchg:sp_min:sp_max:sp_inact:ex_expire:sp_flag That is all fine. The specification for this case will be modified to reflect this requirement and deposited in the case directory as commitment materials (Appendix C - [1]). The committee was fine with the issue. 5. Minority Opinion(s) None 6. Advisory Information None 7. Appendices 7.1 Appendix A: Technical Changes Required None 7.2 Appendix B: Technical Changes Advised None 7.3 Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2010/165). 1.commitment.materials/PSARC-Questionnaire.txt Standard PSARC Questionnaire 2.commitment.materials/ARC-CoverPage.html ARC cover page describing the case and documents included for review 3.commitment.materials/designdocv2.0.9.odt Text Installer Design Document Open Document Text format 4.commitment.materials/designdocv2.0.9.pdf Text Installer Design Document Portable Document Format 5.commitment.materials/spec10-21.html Solaris Caiman Text-based Installer UI Specification non-graphical format On 06/17/10 06:17 PM, John Fischer wrote: PSARC members, The project team has provided updated materials which have been placed under the commitment.materials directory. There is now an ARC cover page (ARC-CoverPage.html) which describes the changes between the inception and commitment materials. I have also added the attached draft opinion which is in the top level directory. There is also an HTML version of the draft opinion in the case directory. Please review these new materials and the draft opinion. Either provide feedback or vote on the case by COB Wednesday, June 30th, 2010. Thanks, John ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/165 - OpenSolaris Text Installer email vote...
On 18/06/2010 17:03, Gary Winiger wrote: On 6/18/10 8:34 AM, Darren J Moffat wrote: On 18/06/2010 16:08, John Fischer wrote: 4.4 User Installed as Primary Administrator The initial user installed by the Caiman installers have been given the Primary Administrator role. The committee pointed out that this role is going away. The issue was discussed in the Solaris Modernization case (PSARC/2010/067). In that case the project team agreed to modify the installers to: Primary Administrator is a Rights Profile not a Role. The distinction is very important. It is the fact that the profile is assigned directly to a user rather than a role what was the whole problem. Also Primary Administrator as a Rights Profile is not planned to go away. Yes it is. PSARC/2009/652 User, RBAC and Labeled Networking Administration will be removing it along with all the suser and act type entries. Primary Administrator is a bug. With root as a role, there is no reason for Primary Administrator. Gary.. P.S. I'll be requesting a case date for 2009/652 shortly. Okay, didn't know about that. Given that can we have the reference put in this cases' opinion then. 7. the initial use is no longer granted the Primary Administrator Rights Profile initial user Yup. No matter how may times the 6 of us read this we didn't catch all the typos ;-( -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010]
I'm restarting this case, given the previous review and the fact that this just addresses the issues it brought up I'm marking it closed approved now. If anyone things it needs further review I'll start a timer. The new technical part spec is as follows (and is in the case directory as spec.txt) Proposal This case is about the architecture of where and in what format CA certifcates are delivered. The specific list of certs to deliver is a business issue for any given distribution. The project team intends to initially deliver the same set of CA certificates that is used in the Mozilla NSS libraries. The project team reserves the right to revise the exact list of certificates and/or choose an entirely different source of certifcates at anytime without requiring further ARC review. A separate X.509 certificate in PEM format for each CA will be placed in /etc/certs/CA/. The files will be named by taking the X.509 DN and replacing the spaces and other unprintables with an '_'. A symlink named using the 'openssl x509 hash' command to each of those PEM files is also created for those consumers that do fast lookups using a hash of the cert DN. The package name is pkg:/system/ca-certs Exported Interfaces +-+ | pkg:/system/ca-certs| Volatile | | /etc/certs/CA/ [1] | Committed | | format CA files (PEM) | Committed | | Exact list of CA files | Volatile | +-+ [1] Note that the /etc/certs directory already exists and is a delivered component of Solaris (via pkg:/SUNWcs). -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010]
On 17/06/2010 16:21, Garrett D'Amore wrote: While ARC may or may not be the best place to review changes to the certificate list (it probably isn't), I think we should like to know how revisions will be made -- i.e. who decides when a change is appropriate and what the change will be? The project team? You? C-Team? P-Team? The appropriate security team at the company producing the distribution based on the OpenSolaris source code. That may not be the same people as the security functionality engineering teams. This is an internal policy decision for each distribution and as such for Oracle's distribution(s) based on the OpenSolaris codebase will not be discussed further here. This project is delivering into the onnv gate the same initial set as what Firefox/Thunderbird uses, other distributions are free to use that as a starting point. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010]
On 17/06/2010 19:29, Garrett D'Amore wrote: I don't think it is necessarily true that these decisions or review, or even a review of the process itself, have to be in the open, but I do think that it is probably best if there is at least an internal closed review covering the process used to manage this list in the final product. One hopes there is a documented process somewhere! For the purposes of this case, a link (even one only available internally) to a document describing the process would IMO satisfy the architectural considerations. There is a process internally, but I won't post the link to this case. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010]
On 17/06/2010 20:07, Garrett D'Amore wrote: There is a process internally, but I won't post the link to this case. Can you at least post it somewhere where the other internal ARC members can see it, or tell them how to verify the process if they should need/want to? Yes. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Removal of pwgen from SFW [PSARC/2010/206 FastTrack timeout 06/11/2010]
On 04/06/2010 19:51, Bart Smaalders wrote: On 06/04/10 11:36, Suhasini Peddada wrote: Hi, I am submitting the fasttrak to obsolete pwgen from SFW Consolidation for Lukas Rovensky and seeking a patch binding. Time out is Jun 11th, 2010. This makes no sense. Why are you removing this? I agree with Bart I don't approve of the removal of this command. Cleaning up SFW is fine but don't throw out useful good small utilities that have very little (or near zero) maintenance. -1. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
PSARC 2010/177 KMF Certificate Name mapping extensions
I'm happy with the technical content of this case so it gets my +1 on the understanding that the project team will be delivering this with PSARC/2010/178 so that there is a mapper delivered with the framework. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Private Crypto Framework header files [PSARC/2010/191 Self Review]
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Private Crypto Framework header files 1.2. Name of Document Author/Supplier: Author: Darren Moffat 1.3 Date of This Document: 25 May, 2010 4. Technical Description In PSARC 2007/215 KCF headers in SUNWhea we started shipping the header files for some of the Consolidation Private interfaces of the crypto framework. One of the nice side effects of that was that the STC security/ef test suite no longer needed to maintain a private copy of the headers. As part of the test development for PSARC 2010/188 we discovered that there were some other Consolidation Private crypto framework headers that could have been included. The main reason for doing this now is to assist with the low level tests in the test suite. This case adds the remainer of the crypto framework headers, that are not for internal interfaces, and where appropriate lint libs. pkg:/system/header /usr/include/cryptoutil.h Consolidation Private /usr/include/sys/ioctl.hConsolidation Private /usr/include/sys/ioctladmin.h Consolidation Private pkg:/developer/library/lint /lib/llib-lcryptoutil Consolidation Private /lib/llib-lcryptoutil.lnConsolidation Private The taxonomy of the interfaces in the headers/library/kernel modules is unchanged and remains Consolidation Private. The release binding for this change is patch. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010]
On 20/05/2010 21:37, Don Cragun wrote: I'm not disagreeing with the move to 32 bytes. I just believe that the ARC needs to make it clear that doing so is a conscious decision to break the ABIs and that it does not set a precedent for other ABI breakage. If I remember correctly, an opinion needs to be written to do that even if this is just a fast track case. No opinion is needed, this case alone is enough. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010]
On 20/05/2010 21:45, Nicolas Williams wrote: On Thu, May 20, 2010 at 01:42:30PM -0700, Alan Coopersmith wrote: Nicolas Williams wrote: In any case, customers that require strict SysV ABI compliance (e.g., customers that have apps that use LOGNAME_MAX and/or L_cuserid and who cannot or will not re-build those apps) can always stick to creating usernames with 8 or fewer bytes. If that is to be a supported scenario, then all system provided account names should remain within the 8 character limit. Obviously they already have to for any case requesting a patch binding for possible backport to an older release, but ARC should decide whether cases that only deliver after this change should be able to add system accounts with longer usernames (postgresql instead of postgres for instance). Not necessarily. We could have pkgs that will only work in a non-standards-compliant installation. Certainly in /contrib :) But, yes, I agree. This could be enforced by IPS or checked for by the recently proposed IPS lint checker. I suspect Darren will claim all of that is not this case. Exactly not this case. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010]
On 20/05/2010 22:06, I. Szczesniak wrote: On Thu, May 20, 2010 at 9:18 PM, Don Cragundcra...@sonic.net wrote: The reason that LOGNAME_MAX was stuck at 8 inlimits.h for so long is that the System V ABIs and the SCDs require that value. Solaris 10 has been breaking ABI requirements around the edges for a few years. Since this is case is departing from more ABI requirements, should it have a major release binding? Or, should an opinion be written for this case acknowledging that the ARC knows that this case violates the ABIs and that the decision to do so is intentional (without setting precedent to otherwise ignore the ABI)? Once upon a time, there was a gang of four working on a definition of what would be the limits of the changes going into Solaris next, whether it would be classified as a major or minor release, and what would constitute the basis for determining whether or not an implementation of OpenSolaris would be able to use the Solaris trademark. Was a report ever produced by the gang? (I know that at least half of the gang no longer works for Sun/Oracle.) Is there any current plan to define any type of new Solaris ABI? I agree with Don that at *least* an opinion must be written for such a change. You will at least break major software like Informix with this change. No opinion will be written unless a full voting ARC member derails the case and takes ownership of it. Note that having an ARC opinion doesn't fix anything all it does is put exactly the same material that is in the fast-track into an opinion document. Which given how simple this case actually is gains nothing. Remeber this change has minor release binding, that makes Informix and anything else that depends on the existing behaviour will still run on Solaris 10 and will still run on OpenSolaris in an S10C zone. If 3rd party applications are broken by OpenSolaris changing to match what other UNIX or UNIXlike systems do already then maybe they aren't using the proper APIs. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010]
On 20/05/2010 18:50, Roland Mainz wrote: Solaris currently documents a maximum username length of 8 characters in passwd(4). Erm... AFAIK this should be _bytes_, not characters. Characters would be multibyte characters in this context with the small twist that It is a effectively a 'char username[32]'. tools like Solaris's tools like useradd always restricted this to the ASCII character set while many sites allow (by using their own set of tools) non-ASCII usernames (e.g. German umlauts are commonly used on German university sites and some japanese customers have been using Japanese characters for some time) and other operating systems even allow a larger set of multibyte characters to be used. IMO this case should either allow the use of multibyte characters or expcitly refer to bytes/ASCII characters (see below). This is is not being extended to support multibyte usernames. I would give this case (if I could) a +1 with two minor changes: 1. useradd should clamp the string to 32bytes but _validate_ that the input username doesn't get any multibyte characters cut-off in the middle. No, it doesn't do that today and that is out of scope for this case. 2. useradd should print a warning if non-ASCII characters (e.g. umlauts in ISO 8859-1/15) or multibyte characters are used unless a specific option is provided (e.g. -W) This is easy to do... if you don't have time I can volunteer to do this modification. It isn't that I don't have time it is out of scope. This case is about one single thing, changing the current limit of 8 to 32. It won't be extended to anything else. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010]
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All
rights reserved.
1. Introduction
1.1. Project/Component Working Name:
PKCS#11 URI parser for libcryptoutil
1.2. Name of Document Author/Supplier:
Author: Jan Pechanec
1.3 Date of This Document:
21 May, 2010
4. Technical Description
Parsing the PKCS#11 URI in libcryptoutil
Overview
Applications start making use of the (not just HW) PKCS#11 keystores for
storing private keys, and to a lesser extend also public keys and
certificates. OpenSSL PKCS#11 Engine already allows applications to
access PKCS#11 tokens that way (6479874) and there is also an ongoing
project to add support for X.509 certificates into SunSSH (6357779)
which also plans to use PKCS#11 keystores for storing private keys
corresponding to certificates. Basically any application that uses
private keys could benefit from having such keys in the PKCS#11
keystores.
However, so far there is no unified way of referencing such keys/certs
in the tokens. Recently we filed an Internet Draft The PKCS#11 URI
Scheme specifying an URI that could help with referencing the PKCS#11
objects. The PKCS#11 URI was already used in the PKCS#11 Engine
(PSARC/2009/555 OpenSSL RSA keys by reference in PKCS#11 keystores
through the PKCS11 engine) and parsing code was included directly into
the engine.
We suggest to put the PKCS#11 URI parsing code into the libcryptoutil so
that it's easily available to all consumers in ON.
PKCS#11 URI Scheme
--
The PKCS#11 URI is fully described in the I-D which is located here:
http://tools.ietf.org/html/draft-pechanec-pkcs11uri-01
Extension to the existing libcryptoutil API
---
Given that libcryptoutil is consolidation private we can define a new
structure in cryptoutil.h, visible in ON. We also use a few new defines.
/* That's what getpassphrase(3c) supports. */
#define PK11_MAX_TOKEN_PIN_LEN 256
/*
* There is no limit for the attribute length in the spec. 256 bytes
* should be enough for the object name.
*/
#define PK11_MAX_OBJECT_LEN 256
/*
* CKA_ID is of type byte array which can be of arbitrary length. 256
* bytes should be sufficient though.
*/
#define PK11_MAX_ID_LEN 256
#define PK11_MAX_PASSPHRASEDIALOG_LEN (MAXPATHLEN + sizeof (exec:))
/* Structure for the PKCS#11 URI. */
typedef struct pkcs11_uri_t {
CK_UTF8CHAR object[PK11_MAX_OBJECT_LEN + 1];
/*
* The objecttype URI attribute can have a value of private,
* public, cert, seckey, or data. The objecttype field can
* have a value of CKO_PUBLIC_KEY, CKO_PRIVATE_KEY,
* CKO_CERTIFICATE, CKO_SECRET_KEY, or CKO_DATA.
*/
CK_ULONGobjecttype;
/*
* CKO_DATA is 0 so we need this flag. Not part of the URI
* itself.
*/
boolean_t objecttype_present;
/*
* Token, manuf, serial and model are of fixed size lengths as
* defined in the specification. The +1s are for the terminating
* '\0's which are not used in the CK_TOKEN_INFO structure
* (fields are padded with spaces).
*/
/* Token label from CK_TOKEN_INFO. */
CK_UTF8CHAR token[32 + 1];
/* ManufacturerID from CK_TOKEN_INFO. */
CK_UTF8CHAR manuf[32 + 1];
/* SerialNumber from CK_TOKEN_INFO. */
CK_CHAR serial[16 + 1];
/* Model from CK_TOKEN_INFO. */
CK_UTF8CHAR model[16 + 1];
/* This is a byte array, we need a length parameter as well. */
CK_BYTE id[PK11_MAX_ID_LEN];
int id_len;
/* Passphrase dialog for getting the token PIN. */
charpassphrasedialog[PK11_MAX_PASSPHRASEDIALOG_LEN + 1];
/*
* The token PIN. Not part of the URI itself. Will be filled
* when the passphrasedialog attribute is used. +1 is for the
* terminating '\0'.
*/
CK_UTF8CHAR pin[PK11_MAX_TOKEN_PIN_LEN + 1];
} pkcs11_uri_t;
We need only one function for parsing the URI, all other helper
functions are static. The function takes a string with the PKCS#11 URI
and fills up a structure allocated by the caller.
int pkcs11_parse_uri(const char *str, pkcs11_uri_t *uri);
Return codes are defined:
#define PK11_URI_OK 0
#define PK11_URI_INVALID1
- the string begins with the pkcs11:// prefix but the URI is
otherwise invalid. It contains an unknown attribute, for
example.
#define PK11_TOKEN_PIN_NOT_READ 2
- there might be different reasons why the PIN has not been
read. For example, the external passphrase-like command does
not exist.
#define PK11_MALLOC_ERROR 3
-
Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010]
On 21/05/2010 12:15, James Carlson wrote: On 05/21/10 04:18, Darren J Moffat wrote: On 20/05/2010 21:37, Don Cragun wrote: I'm not disagreeing with the move to 32 bytes. I just believe that the ARC needs to make it clear that doing so is a conscious decision to break the ABIs and that it does not set a precedent for other ABI breakage. If I remember correctly, an opinion needs to be written to do that even if this is just a fast track case. No opinion is needed, this case alone is enough. On this narrow point, I disagree, and agree instead with Don. I can see no way that changing a #define used in a standard interface is in any way an obvious or uncontroversial change, and thus this easily falls outside of the realm of a proper fast-track. Where is the reference to the standard being #define LOGNAME_MAX ? As far as I'm aware the standards based interface is for C code: sysconf(_POSIX_LOGIN_NAME_MAX); sysconf(LOGIN_NAME_MAX); and for shell code: getconf _POSIX_LOGIN_NAME_MAX getconf LOGIN_NAME_MAX I have no problem with the change itself (even if it does perhaps burn away UNIX branding), but I do think that at least a quick vote and a short opinion stating that are necessary for the record. If a voting ARC member wants to derail the case to do that then that is their choice. However I'm very strongly of the opinion that writing an ARC opinion here is pointless paperwork, it won't change anything and adds no value to what this fast-track already provides in the proposal. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010]
On 21/05/2010 16:19, James Carlson wrote: The second is the standards group branding issue. The value 9 is baked into the UNIX98 and UNIX03 reference materials, so changing it (at least inside those conforming environments) means either re-doing the branding or ceasing to be UNIX in that sense. Obviously not an architectural issue, but something non-trivial that should be noted. My understanding is that this is the distinction between _POSIX_LOGIN_NAME_MAX which this case explicitly stated stays a 9, and LOGIN_NAME_MAX which is only required to be a minimum of _POSIX_LOGIN_NAME_MAX. The #define I'm changing in limits.h is neither of those it is LOGNAME_MAX. The #define in limits.h for _POSIX_LOGIN_NAME_MAX stays at 9. I could be convinced to just take LOGNAME_MAX out of scope and make it Consolidation Private - or maybe to remove it completely. This I believe is Bill's preference. I was hoping to convince you that, although there's nothing wrong with the proposal, and that it's technically simple to accomplish, the nature of it places it outside the bounds of a traditional fast-track, and that allowing mission creep on fast-tracks is a bad thing overall for OpenSolaris. What you aren't convincing me of is what value an ARC opinion will have in this particular case. I see no value in an ARC opinion here since there has been no suggested Advice to any other party. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Username length [PSARC/2010/184 FastTrack timeout 5/27/2010]
On 21/05/2010 16:48, James Carlson wrote: I'm certainly not saying don't do it. In fact, I want to see it happen. Nor am I trying to slow it down. I just want it done _right_. Until such time as an ARC member derails it and asks for it to be voted on it is being done right. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Username legnth [PSARC/2010/184 FastTrack timeout 2/27/2010]
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Username legnth 1.2. Name of Document Author/Supplier: Author: Darren Moffat 1.3 Date of This Document: 20 May, 2010 4. Technical Description Solaris currently documents a maximum username length of 8 characters in passwd(4). Other Operating Systems don't have such a small limit. In fact Solaris mostly works and has for quite some time with usernames upto 32 characters. The 8 character limit is manifest in three places 1) the LOGNAME_MAX constant in limits.h (8) 2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (9) This symbol is deprecated for XPG6 / SUSv3 onwards. 3) getconf _POSIX_LOGIN_NAME_MAX / LOGIN_NAME_MAX (9) The OpenGroup limits.h documentation says that LOGIN_NAME_MAX returns the number maximum number length of a login name and that _POSIX_LOGIN_NAME_MAX is the minumum acceptable value. That implies that they need not be the same. This case changes so that we have: 1) the LOGNAME_MAX constant in limits.h (32) 2) L_cuserid in stdio.h (when __EXTENSIONS__) is defined (33) This symbol is deprecated for XPG6 / SUSv3 onwards. 3) getconf _POSIX_LOGIN_NAME_MAX (9) 4) getconf LOGIN_NAME_MAX (33) Going beyond 32 characters for the username is more complex since utmpx(4) is defined to have the ut_user/ut_name field as 32 characters, changing this would very likely break consumers of getutexent(3C) even if they were all able to be recompiled. This case proposes to change the documented limit in passwd(4) from 8 to 32 and declare that anything not implementing that is a bug. This case does not require that any part of the system enforce 32 as an upper limit (though some may), only that it is a bug that providing it doesn't break standards if they enforce the legacy behaviour of 8 and that they accept and use 32 character long usernames. Work does not require that all output fields that line up with 8 character long usernames still line up when using 32 character long usernames. Ideally code should use sysconf to lookup LOGIN_NAME_MAX but there is also a lot of exsting that derives the size using something like this: (sizeof (((struct utmpx *)0)-ut_name)) The method for fixing utilities that are currently restricted to 8 character usernames is outside the scope of the ARC case and is really an issue for the codereviewers and CRT advocates. Though it is highly recommended that 32 not be hardcoded into a local constant but instead either LOGNAME_MAX from limits.h be used or if possible sysconf(3C), the method of using the ut_name field is acceptable particularly if it means minimal code change. When this case integrates the following bugs will be fixed 4169241 LOGNAME_MAX should be greater than 8. 4033673 passwd cannot be changed if login id is longer than 8 characters 4109819 user names longer than 8 characters needed 4431427 *useradd* useradd(1M) should not complain about a username longer than 8 char 4435330 *logname* logname prints out only part of long login name 4909548 system tools allow to create usernames 8 chars. 4927530 *w* w(1) truncates usernames to 8 chars 6551524 su truncates LOGNAME for long usernames. 6627292 *cron* confused about username lengths 6819489 *su* sulog source username truncated to 8 chars but destination name not 6866548 last command does not support usernames longer than 8 characters 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010]
On 17/05/2010 22:42, Erik Nordmark wrote: On 05/12/10 06:25 PM, Edward Pilatowicz wrote: also, i have the same question as tony. if nwam already supports profiles why is this case even needed? why doesn't install just apply a nwam profile to the system? On 05/13/10 01:27 AM, Darren J Moffat wrote: There has been a very significant amount of engineering work put into NWAM profiles and the case of static configuration was an important part of it. The reason NWAM can't be used is that NWAM has a different notion of static addresses than what we provide for enterprise servers using network/physical:default. NWAM's notion of static is reactive in the sense that the static configuration is not applied if the link isn't up (cable plugged in), whereas the network/physical:default applies the configuration whether or not the link is up. Thus replacing network/physical:default with a static NWAM profile would introduce a new failure mode; if the cable is unplugged the server can no longer talk it itself, and server applications that bind to the local IP addresses of the system would fail - since the addresses wouldn't be configured when the link is down. Hence we can't use NWAM for this right now. Thanks for that explanation, that makes a lot more sense as the reason why NWAM can't be used than wither or not the NWAM configuration of a static profile is in an SMF xml fragment or not. One of the many projects underway in this area is to consolidate NWAM and physical:default. The NWAM engineers are involved in this and other network configuration projects. That helps too. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010]
Support for configuring NWAM via SMF properties doesn't exist. And the Install team would prefer to not have to understand the details of an NWAM profile to create one themselves. Sorry but that comment alone is grounds for derailing the case. There is an existing profile based architecture that already deals with all of the things this case can do and much more. Please put this case in waiting-need-spec and have the spec updated with detailed information on why using an NWAM profile with a static rather than DHCP based configuration won't work. When that information is available the case can be re-railed if it is still even necessary. There has been a very significant amount of engineering work put into NWAM profiles and the case of static configuration was an important part of it. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010]
With Mark's clarification I'm comfortable with this continuing as a fast-track for now. I share the concern about NIS and LDAP not being covered but I don't see that the architecture of this case precludes equivalent services for those being added (if anything it sets precedence for how to do it), for the SMF issues I'm happy to defer to the SMF experts. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: GNOME 2.30 [PSARC/2010/143 FastTrack timeout 04/30/2010]
On 23/04/2010 04:05, Brian Cameron wrote: 2.2.4 GNOME Shell and OpenGL GNOME Shell will likely be the default window manager from GNOME 3.0 and it requires OpenGL support. This may be a problem for environments that do not support OpenGL such as Sun Ray. To solve the problem, the GNOME community proposes that GNOME 2 will still be available in long term stable maintenance mode. Environments lacking of OpenGL support can continue to use GNOME 2. The Desktop team is working with the upstream community to determine the best course of action to provide a modern desktop on systems without OpenGL support. Not relevant to this case review since it is about a future release. If GNOME Shell is just the window manager, ie replaces metacity then can't systems not wanting to (or unable to)use OpenGL window managers continue to use metacity (or some other lighter weight WM) but have the rest of GNOME 3 ? 2.2.5 The adoption of upower and udisks From GNOME 2.28, GNOME community starts to use upower and udisks (previously called DeviceKit-power and DeviceKit-disks) to replace HAL. A significant amount of work has been done for GNOME 2.30 and the dependency of HAL will be fully removed in GNOME 3.0. Gnome-power-manager now depends on upower and has abandoned the dependency of HAL. Because upower is not shipped in Solaris currently, we plan to continue to ship gnome-power-manager 2.24 in GNOME 2.30. Other applications still depend on HAL optionally for GNOME 2.30. So this is not a big issue for now, but may be a risk for the integration of some GNOME components in the future. So what work needs to be funded in the desktop consolidation and other consolidations to allow the move away from HAL to upower/udisks ? This seems like potential ARC opinion fodder, but only necessary if the coordination hasn't already been discussed between the relevant engineering teams (basically no need for an opinion just for this). -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
lofi(7D) in non global zones [PSARC/2010/144 FastTrack timeout 04/30/2010]
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: lofi(7D) in non global zones 1.2. Name of Document Author/Supplier: Author: John Levon 1.3 Date of This Document: 23 April, 2010 4. Technical Description 1. Introduction This case enables the safe use of the lofi(7d) driver and utilities within a non-global zone. A patch binding is requested. 2. Device visibility Currently, it's not possible to usefully create lofi devices inside a non-global zone. This project modifies the lofi(7d) driver and related code such that each lofi node is owned by a particular zone. The zone owner of each node is stored as a DDI property zone, for example: # prtconf -v /dev/lofi/1 lofi, instance #0 Device Minor Nodes: dev=(144,1) Minor properties: name='zone' type=string items=1 dev=(144,1) value='ozone' This property is looked up by the devnames zone profile code in order to filter visibility of lofi nodes within the zone's mounted /dev instance. Within each zone, lofiadm(1m) is only allowed to see, or modify, the nodes it has created. The global zone can access all nodes, however, for example: # lofiadm Block Device File Options /dev/lofi/1 /rpool/zones/ozone/root/var/lofi/lofi_file_736429_44 - ... If the path cannot be resolved from the global zone (for example, it may reside on an NGZ-mounted NFS path), the File column displays ?. When a zone is shut down, all its lofi devices (and any mounts on top) are unmapped and destroyed. As today, only root users may access and modify lofi devices. 3. Resource limits Currently, lofi has a limit of 128 devices. This case removes this limit as it is not extendable to the multi-zone case. Instead, the number of lofi devices is restricted by each device's associated taskq: the lofi taskq is created as zsched thread, and the zone resource control max-lwps applies. lofiadm traditionally allows direct specification of the minor number to use when creating a mapping. Since direct lofi mounts, this feature is a lot less useful; however, this case continues to support it. A maximum minor number of 65536 is enforced. Note that the minor number space is not virtualized across all zones, thus a non-global zone can observe minor number allocation. However it cannot request mapping information or modify other nodes. 4. Mounting lofi devices The direct mount support introduced in PSARC 2008/290 works as expected in non-global zones. Allowing lofi devices into non-global zones introduces a security issue. Some filesystems (notably UFS) are not sufficiently protected against corrupted or maliciously constructed filesystem images, which lofi allows the zone root user to modify. This could potentially lead to a non-global zone panicking the kernel. Therefore, mounts within a non-global zone are restricted to a given allowed list of filesystems, as described in Section 5 and Section 6. This applies to all mounts not just lofi ones. 5. New vfs flag VSW_ZMOUNT The default list of allowed filesystems is based upon a new vfsdef_t flag VSW_ZMOUNT. If set, then the filesytem may be mounted within a zone, regardless of the fs-allowed value. This flag is Consolidation Private. Today, this flag is set for pseudo filesystems such as proc, network filesystems such as NFS, plus the hsfs filesystem. Future work may enable other filesystems by default. Currently, a non-global zone can create a ZFS volume, but it is not visible inside the zone's /dev. This case doesn't attempt to fix this, although future work may enable it. 6. fs-allowed zone property Although we cannot guarantee the safety of this, this case also defines a new zone property to allow the administrator to add filesystems to this approved list. The property fs-allowed is a list of filesystem names that may be mounted from within the zone, in addition to the ones already allowed. For example, to also allow access to pcfs and ufs mounts: # zonecfg -z ozone zonecfg:ozone set fs-allowed=ufs,pcfs This property does not affect zone mounts administrated by the global zone via add fs or add dataset. This property applies to all zone brands except lx, where it is not allowed to be set. This propety is Committed. 6. References PSARC 1999/463 lofi - fast-track PSARC 2008/290 lofi mount 6354954 lofi support in non-global zones 6946536 would like zvol support in non-global
Re: libinetcfg removal [PSARC/2010/142 FastTrack timeout 04/29/2010]
On 22/04/2010 15:56, Sebastien Roy wrote: I'm submitting this fast-track for Anurag Maskey. It times out on 04/29/2010. The release binding is Minor. Libinetcfg library removal -- Sounds like all the necessary due diligence has been done so +1. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: [desktop-discuss] GDM Integration With audioctl [PSARC/2010/116]
On 08/04/2010 14:14, Garrett D'Amore wrote: On 04/ 8/10 02:10 AM, Darren J Moffat wrote: On 07/04/2010 18:39, Albert Lee wrote: The PreSession script could check the ownership of /dev/audio and only call audioctl load-controls if /dev/audio is already owned by the user. It is a bit of a drag to follow all the /dev/audio symlinks, but it would be smarter. Something that may have to be addressed eventually is dynamic switching between multiple X sessions (fast user switching). Maybe a note should be made that the design here will have to be revisited if this is ever supported. That would be more relevant to the currently running case PSARC 2010/119 Console User assignment, logindevperm and virtual console update. Since that case actually ensures that with multiple X sessions only the first (ie :0.0 display) has access to the audio device anyway. If the intent is to allow switching of the audio devices then both this case and PSARC/2010/119 need to coordinate and both probably need updated specs. However I don't believe that is the intent because taking away the audio (or other logindevperm assigned devices) on fast user switching could actually cause applications currently running to fail. Oh wow. I'm working on something that could be a fix for that. Basically, we can switch the plumbing *underneath* the application pretty easily now, and direct the other session to a sink. We could also provide mixing of all applications if that is more desirable. I think we ought to have a conference call to discuss this in more detail... there are multiple options here and I'd really like to try to tackle this correctly. Audio is only one part of the picture though. What about all the other usb attached devices that logindevperm will be switching owner of: disks, video, ugen etc. What will do you about the webcam that is recording stuff ? Or the disks that are mounted ? -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: zil synchronicity [PSARC/2010/108 FastTrack timeout 04/08/2010]
On 01/04/2010 18:28, Neil Perrin wrote: We've flip-flopped on whether it should be inherited. It's currently coded as inherited, and I know Robert believes it should stay that way. Anyway, it was generally felt by the zfs group that sync=disabled was sufficiently dangerous to require explicit setting on each dataset. I would be ok with it being inherited. I agree that it is dangerous but I'm not sure that the change in semantics means it shouldn't be inherited. On the other hand I can't think of any other equivalently dangerous (to applications view of the world) per dataset property. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: zfs diff [PSARC/2010/105 FastTrack timeout 04/05/2010]
On 30/03/2010 21:36, Nicolas Williams wrote: On Tue, Mar 30, 2010 at 02:04:39PM -0600, Tim Haley wrote: It would be easy enough for me to print a 'time' column as the first column, and the output could then be sent to 'sort -n'. I'm not sure how people feel about that. Is that cheating? :-) The alternative is to AVL sort by that time, which as you note will increase the footprint, perhaps dramatically for a really big diff. I'd be happy with that. Someone suggested a -o field1,field2,..,fieldN option, and that's starting to look desirable. There's at least these fields that you could include in output: - object number I don't see what use the object number is to anyone parsing the output of 'zfs diff' particularly since there is no way for them to translate it to anything meaningful. The object number is an internal ZFS representation. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: zfs diff [PSARC/2010/105 FastTrack timeout 04/05/2010]
On 30/03/2010 19:34, johan...@opensolaris.org wrote: On Tue, Mar 30, 2010 at 10:31:04AM -0700, Bart Smaalders wrote: On 03/30/10 09:58, Glenn Brunette wrote: Dan, I have to +1 all of your well-thought-out comments. As a potential consuming of this functionality for the Immutable Service Container project, answers to these questions are critical. I am also interested in whether additional fields can be added to the output similar to a -o field1,field2 scenario? It would be nice to have data such as file type, modification time (where applicable). Also, will this functionality be able to tell how files were modified? Things like changes in file ownership, group membership, permissions and ACLs, size, times, etc.? Even if this processing is not directly implemented as part of the zfs diff command, perhaps the fields could be made available (per -o comment above) to be consumed by layered tools? A very detailed human readable diff of file attributes seems a lot of additional work to place on zfs diff. Isn't a list of what is different sufficient to give to another program? This portion of the discussion makes me wonder if there would be some value in developing a prototype of 'zfs patch'. Designing patch might help illuminate some of the attributes that should be machine-readable by default. If certain portions of the diff/patch implementation are For 'zfs patch' to be useful it would need to include the data as well not just the metadata. That is exactly what 'zfs send | zfs recv' is. -- Darren J Moffat ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
