[request-sponsor] no response for 6299120
Bonnie Corwin wrote: When a bug is moved to 'suspended', it is by definition available to anyone to pick up. The original contributor can come back later and request a sponsor again or someone else can pick it up and request a sponsor. So what is the reason for having a suspended state in that case it seems no different to back on the available list. -- Darren J Moffat
[request-sponsor] request-sponsor BUG ID: 6638715
vinay simha wrote: name1 : Vinay Simha.B.N email id: simhavcs at gmail.com mailto:simhavcs at gmail.com name2 : Beeresh.G email-id: beeresh at gmail.com mailto:beeresh at gmail.com Bug ID Number :* 6638715* synopsis:Checks in passwd should be role based, not uid based category : utility subcategory : other description : The passwd command still uses uid checking for modifications to the file repository: This will need an ARC review but before doing so I HIGHLY recommend that the design for this is discussed on security-discuss before hand. 6206564 is a related bug which was fixed in snv_09 and lays down some infrastructure that this bug could use in its fix. -- Darren J Moffat
[request-sponsor] Bug 6449291 package prototype files in usr/src/pkgdefs/SUNWipfh missing CDDL
John Beck wrote: avinashtjoshi But there is a small problem. Whenever we request for a avinashtjoshi sponsor, we dont get any reply for days! In this case, avinashtjoshi what can we do? As others have mentioned use the project and community aliases appropriate for the fix you are doing to get codereview. If you can't find an appropriate alias try the opensolaris-code alias. You could wait, or you could contribute a more meaningful fix. I don't mean to make light of the many contributions that have been offered recently, but a very high percentage of them are for trivial problems that we would generally rate as low or very low priority. As such, most of us have higher priority things to work on. I'd be a little stronger than that. Fixing typos in comments doesn't improve the quality of the resulting binaries and given the high a process burden while we are still using the sponsor system to me it just isn't a good use of a sponsors time. I would personally rather see that we don't see requests that are just fixes in comments. I do want those fixes in the code base but in my opinion they are better done as part of another set of changes in a similar area of the code base or subsystem. Fixes to spelling and grammar that appear in user interfaces are a different issue but as John said they are still often very low priority things. Don't take this that I don't value the work that people are offering I do but until we have OpenRTI and direct putback these I don't see that it is a good use of everyone's time. -- Darren J Moffat
[request-sponsor] Fix for bug 6558327
Vidyalakshmi wrote: Hi, We are Deepthi Devaki A R(SCA No. OS0172 ) and R Vidya Lakshmi ( OS0171 ). We were working on the bug 6558327. We have fixed the bug. Bug ID 6558327 Synopsis the opposite of 'init' is not 'uninit' State 6-Fix Understood (Fix is known) Category:Subcategory utility:zfs I've just noticed that this bug has an engineer (cc'd) already assigned to this have you asked them if you could take it over ? You need Doug's permission before taking the bug over and before I can sponsor it for you. In general please don't pickup and work on bugs if they have a Responsible Engineer assigned until you have contacted the engineer first. -- Darren J Moffat
[request-sponsor] Fix for bug 6558327
Vidyalakshmi wrote: Hi, We are Deepthi Devaki A R(SCA No. OS0172 ) and R Vidya Lakshmi ( OS0171 ). We were working on the bug 6558327. We have fixed the bug. Bug ID 6558327 Synopsis the opposite of 'init' is not 'uninit' State 6-Fix Understood (Fix is known) Category:Subcategory utility:zfs We are attaching the diff file here with I'll sponsor this for you. -- Darren J Moffat
[request-sponsor] Bugid: 6506683 Category:Subcategory utility:shell
Visakh M R wrote: hi, I found this bug interesting and i wish to work on it: Bugid: 6506683 Synopsis Add a simple command to search for installed files in solaris systems Category:Subcategoryutility:shell SCA no: OS0192 is there any procedure for approving a new command? Yes see the ARC community. However I'm not even sure if this bug needs to be fixed since the pkgchk(1) command can already do what I think this bug is asking for. $ pkgchk -v -P bin/vim /opt/csw/bin/vimtutor /usr/bin/vim /usr/bin/vimdiff /usr/bin/vimtutor -- Darren J Moffat
[request-sponsor] Requesting sponsor for bug 6339753 - nsswitch should allow comments in local files
Ceri Davies wrote: I'd like to request a sponsor for bug 6339753, allowing nsswitch files backends to use comments. The fix is seemingly trivial but I particularly want guidance on whether comments should only be allowed when they begin a new line, in order to avoid breaking existing databases. I think this is quite a big issue. There is no defined comment char for some of these databases, including /etc/passwd and /etc/shadow. Fixing this effectively introduces a comment char. On the other hand for databases like user_attr(4), exec_attr(4), prof_attr(4) there is a defined comment char (and it is '#'). Simply allowing this via nsswitch is only part of the issue, what happens to all the tools that modify all the files backend nsswitch databases ? What should they do with comments ? I think this needs further discussion somewhere other than request-sponsor. Since this is mostly nameservices related I think the best alias is sparks-discuss@ however I also suspect that many of the security-discuss@ subscribers would be interested in this too. -- Darren J Moffat
[request-sponsor] Requesting sponsor for zpool split : 5097228
Jeremy Teo wrote: Hello, requesting a sponsor for the above mentioned. :) Thanks! Do you have code ready ? This will need ARC review as it adds a significant new bit of functionality that is visible to the admin. For something this significant I'd highly recommend writing the full proposal including draft diffs to the man pages and sending it to zfs-code and or zfs-discuss first. -- Darren J Moffat
[request-sponsor] bugid: 6503301
Joep Vesseur wrote: Erwin, Erwin van Eijk wrote: - - how can I/anyone update the bugid to also state that other misspellings are accepted? I know bugzilla offers a feature like this, but I wasn't able to find it on the opensolaris bug database. For now, bugs can only be updated from inside Sun. - - is the intention to fix the bug, as described in the bugdatabase, or such that all invalid commandlines are properly marked as being invalid? It seems reasonable to make the command behave in general, so I'd say that it makes sense to fix all the known bugs related to this. I can help you work on this. I agree with Joep. When it comes to codereview and if you have any technical questions need answered contact the crypto project crypto-discuss at opensolaris.org. You might want to even considering adding in this oss-bite-size bug too: 6366102 cryptoadm provider= could do with some wild carding -- Darren J Moffat
[request-sponsor] Re: [osol-discuss] 2 new request-sponsor putbacks: 45 total
Cyril Plisko wrote: On 3/16/06, Jim Grisanzio Jim.Grisanzio at sun.com wrote: Thanks to Rich Lowe and Robert Milkowski for these two bug fixes below and to Sarah Jelinek and Darren Moffat for sponsoring the fixes through to putback. Also note that Robert's led to an ARC case. Will this PSARC case be published on opensolaris.org site ? Yes, ideally almost very case should be published but the infrastructure to do it automatically isn't in place yet. -- Darren J Moffat
[request-sponsor] Re: ARC table request
Bonnie Corwin wrote: See: http://opensolaris.org/os/bug_reports/arc_table Great, thanks! -- Darren J Moffat
[request-sponsor] Bug 6412936: no event data is received from a Apple Mighty Mouse
J?rgen Keil wrote: This is a sponsor request to fix support for the Intel iMac USB mouse. The suggested for for the issue is included in the bug report: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6412936 I'll sponsor this one. -- Darren J Moffat
[request-sponsor] 6416837 /usr/ucb/ls needs /bin/ls enhancements
Since this changes the interface of /usr/ucb/ls it will need ARC review, I strongly recommend taking that path before worrying about the implementation. In general I'm not sure why anyone would want to change the behaviour of /usr/ucb/* they are legacy and intended to be frozen in time - in my opinion anyway. If you do get ARC approval to make these interface changes to /usr/ucb/ls then I'd highly recommend option 3 on your list. While it will be complex to setup it does ensure that there is only one implementation of the complex functionality such as ACL setting and output. Out of curiosity why do you use /usr/ucb/ls rather than /usr/bin/ls or /usr/xpg?/ls ? -- Darren J Moffat
[request-sponsor] 6626730 remove from list
I have had no response to any of my requests to the original requester for code or ARC material. Please remove this from the sponsor list. -- Darren J Moffat
[request-sponsor] patch for bug 6551524
ashwin wrote: HI I have the patch for bug id 6551524 Requesting sponsor for the same. My SCA Number is OS0144 Synopsis : su truncates LOGNAME for long usernames. Category:Subcategory: utility:security change to be made in file - onnv/onnv-gate/usr/src/cmd/su/su.c link to the bug - http://bugs.opensolaris.org/view_bug.do?bug_id=6551524 description su does not set LOGNAME environment variable correctly for usernames longer than 10 characters. So the size of array logname is changed from 20 to 30 Have attached the diff. I'll sponsor this. Note that your fix isn't one I'd accept. The target for username length is 32 because that is the maximum that can be store in the utmpx ut_user field. So the fix needs to ensure that a 32 char long username will work. We can work out the details of how best to do that offline. -- Darren J Moffat
[request-sponsor] Fwd: Bug 5029936 remove mech_dh's private copy of MD5 function
Rishi M Nair wrote: Hi , I would like to work on the bug : 5029936 and will finish working on it within 1 week. (I dont have a fix ready yet) Bug ID 5029936 Synopsis remove mech_dh's private copy of MD5 function Category:Subcategory gssapi:generic My SCA number is : OS0148 My opensolaris id : rishios What is the status of the fix for this ? If it is ready or near ready I maybe able to sponsor it for you. -- Darren J Moffat
[request-sponsor] Fwd: Bug 5029936 remove mech_dh's private copy of MD5 function
Avinash Joshi wrote: sir, I am working with Rishi on this bug.. We tried a lot to find the similar functions. We am a bit confused on this bug. What exactly am I supposed to do? We will be greatful to you if you could send me some details on this bug. I've updated the bug with some more info. -- Darren J Moffat
[request-sponsor] Removals from list of active sponsor requests
Please remove the following bugs from the sponsor list the original requester is no longer working on them: 6551524 su truncates LOGNAME for long usernames. 6627292 *cron* confused about username lengths I've already updated bugster. -- Darren J Moffat
[request-sponsor] 5029936 suspended
The requestor is not responsive please remove this from the list of pending requests. -- Darren J Moffat
[request-sponsor] 6488593 remove from list
6488593 required ARC approval which it didn't get. Also the requester is now a Sun employee and should purse this on their own. -- Darren J Moffat
[request-sponsor] Requesting sponsor for CR #6605094: netgroups for Allow|DenyUsers in SunSSH
Peter W. Osel wrote: Hello, I would like to request a sponsor to help me integrate the changes for CR 6605094 support the use of netgroups in AllowUsers and DenyUsers configuration options in SunSSH. We have implemented this change in OpenSSH and have already been using it for many years. I am trying to get this change pushed upstream into OpenSSH, too. The changes are fairly small, e.g. the context diff (including man page changes) for OpenSSH 4.5p1 is just 131 lines, the changes to SunSSH should be very similar. Given that OpenSolaris has a pam_list module that supports netgroups do we even need this ? -- Darren J Moffat
[request-sponsor] Interested in working on Enhancement 6306504
Sergio Gutierrez wrote: Hello everybody. I am not sure if enhancement 6306504 (Command for locking a TTY session) is free to be worked on, or it is been done by somebody else. In case it be free, I would like to work on it. Contact Rich Teer about this, he was planning to do this and I have already sponsored and gotten approved the ARC case for the design. Rich hasn't given me code to integrate as yet. Also please check in with the virtual consoles project as they are implementing vtty locking in that project. -- Darren J Moffat
[request-sponsor] Requesting sponsor for CR 4912090: pfzsh should exist
In addition to what Casper said addition of pfzsh would require ARC approval. Given that the FGAP project intends to do away with the requirement for modified versions of the shell PSARC may or may not approve the implementation of pfzsh using the existing method. Regardless PSARC approval is the next step here if you wish to get this integrated as a stop gap before FGAP integrates. However I would say that at this stage adding pfzsh without also adding pftcsh, and pfbash isn't that useful. -- Darren J Moffat
[request-sponsor] Bug 6570559
Rishi M Nair wrote: Hi All I would like to request a sponsor for bug 6570559 My open solaris id is rishios and SCA Number is OS0148 This CR apparently already has and engineer assigned. If bugs.opensolaris.org has an entry for Responsible Engineer please always contact that engineer and get agreement with them before requesting a sponsor. Have you done so ? Also in this specific case I suspect that the most interesting case isn't so much OpenSolaris, though that certainly needs fixing, but patches for older Solaris releases. The later can only be done internally to Sun, but that doesn't stop someone external like yourself contributing the OpenSolaris fix. -- Darren J Moffat
[request-sponsor] [6365813] sponsor request
ashwin wrote: Hello guys. Requesting a sponsor for bug # 6365813 My contributer's agreement is OS0144 Bug Details: ssh corrects confusion with more confusion network/ssh's refresh method is /lib/svc/method/sshd restart, which seems uncouth, since refresh methods should not stop the daemon. But, in fact, /lib/svc/method/sshd restart just runs /usr/bin/kill -HUP `/usr/bin/cat $PIDFILE`, which doesn't stop the daemon at all. The argument should be changed to refresh. I'll be your sponsor. I'll contact you directly on the fix details. -- Darren J Moffat
[request-sponsor] Requesting sponsor for CR# 6488593 (/etc/profile should set TMPDIR to /tmp/$LOGNAME/) ...
Roland Mainz wrote: Hi! Requesting sponsor for CR# 6488593 (/etc/profile should set TMPDIR to /tmp/$LOGNAME/) - patch is included in the RFE... This will I believe need an ARC case since it is a change in default behaviour. It also should be done for all shells not just ones that read /etc/profile. Since I do this myself in my own .profile I feel duty bound to stand up to the plate and by your sponsor for this. So sign me up for putback sponsor and I'll be ARC case submitter too. -- Darren J Moffat
[request-sponsor] Requesting sponsor for CR# 6488593 (/etc/profile should set TMPDIR to /tmp/$LOGNAME/) ...
Casper.Dik at Sun.COM wrote: Since I do this myself in my own .profile I feel duty bound to stand up to the plate and by your sponsor for this. So sign me up for putback sponsor and I'll be ARC case submitter too. Good idea (I use this myself :-)). Should the directory be created 700 by default? There's a risk in setting $TMPDIR and making it mode 700; the risk is that programs started under a different uid may start to fail. pkgadd is one of those programs. But it should either by mode 1777 (to mitigate that risk) or 700 for privacy. Or honour the umask ? -- Darren J Moffat
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
Mike Gerdts wrote: On 10/30/06, Darren J Moffat Darren.Moffat at sun.com wrote: James Carlson wrote: Why, other than the returning an error we already have 5 such privileges in the basic set. Now in each of those cases (proc_info, proc_session, proc_fork, proc_exec, file_link_any) there is a way to return an error for sync(2) but there is for 'lockfs -f'. I assume the above was supposed to be there is no way to return an error for sync(2)... Yes I did. It seems as though the key interest in non-root users being able to run sync(1m) is in reaction to some perceived doom on its way (thunder that comes a few seconds after the lightning, etc.). If sync(2) were change to check for a privilege (PRIV_SYS_SYNC?) before calling vfs sync(), it indeed would not return an error. However, sync(1m) could do the same check that sync(2) does and return the appropriate error. What check ? Only the kernel (and the Xserver when TX is running) checks privileges, applications should never check privileges and make assumptions based on them. 'lockfs -f' seems as though it would be able to get an error from ufs_fioffs(). Yes or from the equivalent for other filesystems that implement that ioctl as well. Does it make sense to progress with this as: 1) Create a new privilege PRIV_SYS_SYNC Seems as reasonable a name as any. 2) Alter sync(2) or vfs_sync() to only perform the sync if the calling process has PRIV_SYS_SYNC. Either is probably fine. 3) Alter ufs_fioffs() to only perform the sync if the calling process has PRIV_SYS_SYNC. On failure return EPERM. Yes and check ZFS and the other filesystems too. 4) Alter sync(1m) to check for PRIV_SYS_SYNC and say Permission Denied and exit with a non-zero value if the permission is not held. No applications should not check privileges, though in this case it might be okay since you know you need sys_sync to call sync(2) and if you don't have it what is the point. In the general case though one is supposed to try the operation rather than assume based on the privileges one has. 5) Alter rc0.sh to only call sync(1M) if running in the global zone. 6) Alter svc.startd(1M) to only call sync(2) if running in the global zone. I'll leave those to a zones expert to answer. Assuming we do steps 1 and 2 above, do we get into any problems with POSIX compliance if the default basic privilege set does not include PRIV_SYS_SYNC? As soon as you manipulate the privilege sets you are already operating outside of POSIX so it doesn't apply. -- Darren J Moffat
[shell-discuss] Re: [request-sponsor] Requesting sponsor for CR# 6488593(/etc/profile should set TMPDIR to /tmp/$LOGNAME/) ...
Casper.Dik at Sun.COM wrote: Casper.Dik at Sun.COM wrote: Yeah, you'll notice that if you try to su to root and run installers that run pkgadd internally. I use this method, and the StarOffice 8 installer failed quite mysteriously until I realized it was just an instance of that problem and reset TMPDIR to something else. This, unfortunately, kills the whole idea in my mind. (I vaguely remembered similar issues from the past) Why ? the whole idea is about usuablity and not security (see my other postings) ... Ok, if the proposal is ammended to mode 1777 then that is good. I'm happy with that too. -- Darren J Moffat
[shell-discuss] Re: [request-sponsor] Requesting sponsor for CR# 6488593(/etc/profile should set TMPDIR to /tmp/$LOGNAME/) ...
Joerg Schilling wrote: Peter Tribble peter.tribble at gmail.com wrote: I regard this as unsafe and undesirable *as a default*. It clutters up /tmp with unnecessary directories, wastes memory and involves extra code at login. I have no problem with administrators or users doing it if they want, but I see no advantage to having it as the default behaviour. I concur. I actually think it is a very good idea. I seriously doubt the amount of memory it wastes by having directories is actually important to anyone. While it isn't particularly necessary on machines with small numbers of users if you have every logged into a big Sun Ray machine you would have an idea of just how cluttered /tmp can get with hundreds of users all using the same /tmp. The way to take this forward is for the original requester to write up the ARC case and I as sponsor will get the ARC case submitted. -- Darren J Moffat
[shell-discuss] Re: [request-sponsor] Requesting sponsor for CR# 6488593(/etc/profile should set TMPDIR to /tmp/$LOGNAME/) ...
Mike Gerdts wrote: On 11/6/06, Darren J Moffat Darren.Moffat at sun.com wrote: While it isn't particularly necessary on machines with small numbers of users if you have every logged into a big Sun Ray machine you would have an idea of just how cluttered /tmp can get with hundreds of users all using the same /tmp. On such machines, are the files that land in /tmp ones that respect $TMPDIR or is it deliberate acts of users that clutter /tmp? By deliberate acts I mean a sequence similar to: I would like to see what is in this tar file; cd /tmp ; tar xvf ~/file.tar; darnit! That tar file didn't have a single top level directory; A mixture in the general case, but on the Sun Ray servers I personally use it is almost never user induced clutter because they are only used by developers/engineers who know better than to dump stuff in /tmp :-) I am not at all opposed to this proposal, I just suspect that a standard /tmp cleaner utility would have more impact. That is, do for /tmp cleaning what logadm has done for log rotation. Thats a near impossible problem to solve in my opinion. If this is a problem that is restricted to the case of a handful of situations related to particular applications, it may be useful to have /etc/profile process files in a directory named /etc/profile.d. I've personally not yet formulated an opinion on whither or not I like the /etc/profile.d stuff I've seen on other systems. If feels icky since it looks on some systems just like reintroducing all the problems of SVR4 init to the users profile :-) This way the Sun Ray software could add a file into that directory that sets TMPDIR without performing the risky task of modifying /etc/profile as a postinstall script. Having /etc/profile.d (and similar for *csh users) would certainly simplify local customization of environments without having to worry about patches or upgrades whacking them. I could but I see the exact same problem on machines that people do lots of ssh access to so it isn't actually a Sun Ray induced problem, though the fact that GNOME likes lots of temp files certainly increases it some what. -- Darren J Moffat
[request-sponsor] requesting sponsor for 6490848, 6490789, 6490780, 6490925, 6490777, 6490985, 6490715, 1214359, 6490935, 6490855, 6490754
River Tarnell wrote: 1214359 *passwd*:passwd does not allow -egh arguments for files repository So you are proposing to change the man page rather than fix the problem? If so then we should use a new separate man page bug for this and leave the original 1214359 RFE open. Or are you interested in addressing the original RFE ? If so it will likely need an ARC case - which I'd be happy to sponsor for you. -- Darren J Moffat
[request-sponsor] requesting sponsor for 6490848, 6490789, 6490780, 6490925, 6490777, 6490985, 6490715, 1214359, 6490935, 6490855, 6490754
Darren J Moffat wrote: River Tarnell wrote: 1214359 *passwd*:passwd does not allow -egh arguments for files repository So you are proposing to change the man page rather than fix the problem? If so then we should use a new separate man page bug for this and leave the original 1214359 RFE open. Never mind me I see now that your 6490935.diff file has the changes for 1214359 in it as well. Or are you interested in addressing the original RFE ? If so it will likely need an ARC case - which I'd be happy to sponsor for you. This will still need ARC review since it adds a new interface. I'll sponsor 1214359 and 6490935 for ARC and putback. River we can take this offline to write up the ARC fast-track case and get that submitted first. -- Darren J Moffat
[request-sponsor] disable console bell in the kernel
Doug Scott wrote: I have noticed, a few posts asking how to disable the console beep/bell on some laptops. While it is possible to disable some applications such as bash, and gnome, you should be able to disable it globally with the kdb command or in /etc/default/kbd. This can already be done for the keyboard click, and should be extended to the console bell. The changes are relatively simple, as adding an option (-b on|off) and code similar to keyclick in /usr/src/cmd/kbd/kbd.c. The appropriate ioctl KBD_CMD_BELL and KBD_CMD_NOBELL are already in sys/kbd.h. Possibly changes may need to made to /usr/src/uts/intel/io/beeper.c (and code for other platforms). This will need ARC review so you will need an ARC sponsor was well. Whom ever steps up to be your code putback sponsor can help find an ARC sponsor for you (hint I'm willing to do that bit). -- Darren J Moffat
[request-sponsor] platform support for TAD,Viper (CR 6458566)
Garrett D'Amore wrote: I would like to work on getting the core platform support (namely /platform links and the custom platmod support) for TAD,Viper into OpenSolaris. The bug came in with CR 6458566, and it is not in b.o.o yet. I'll take this one, if or no other reason than Garrett and I have worked together before. Note that this will need a quick simple ARC case to reserve the name into $PLATFORM namespace, I'll sponsor that part as well. -- Darren J Moffat
[request-sponsor] 6200108 - encrypt -l fails if output is redirected
On Wed, 2005-11-09 at 20:24, Richard Lowe wrote: Patch for bug 6200108 - encrypt -l fails if output is redirected http://richlowe.net/patches/6200108.diff contributor agreement #OS0007 I'll sponsor this one. -- Darren J Moffat
[request-sponsor] Reminder: Requesting sponsor for 5007466 PSARC/2004/480
Joerg Schilling wrote: Hi, I am still waiting for a sponsor for integrating star. Star is an archiving library that implements CLIs for various archiver programs and that implements various archive formats. Are you wanting to integrate this into the ON consolidation or to SFW ? If you are targeting SFW (and I strongly suggest you do) then you may have better success getting help by posting a webrev of the changes to SFW to the sfw-discuss at opensolaris.org alias. I'm afraid I'm not personally skilled enough in SFW to act as your sponsor. Though I've prototyped the changes necessary for star in the past to integrate into SFW and you can find those in the sfw-discuss archives. If you are targeting ON then this is the appropriate alias to use, but someone else will need to help you as I'm quite opposed to integrating cross platform stuff into ON if it doesn't have to share private interfaces with some thing else in ON - it just hurts the portability and maintenance of that thing. Note I speak from (bitter) experience here with Kerberos, SSH, OpenSSL and others being in ON. If you do still want to target ON (or in fact SFW) you may have better luck finding a sponsor if you post a webrev of the proposed changes. Good luck in finding your integration sponsor. -- Darren J Moffat
