[request-sponsor] 6465105
Hi Jeremy, You wrote: Request sponsor for #6465105 ZFS does not update timestamps upon the creat() of an existing file. 6465105 ZFS does not update timestamps upon the creat() of an existing file http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6465105 I can sponsor this bug as per: http://www.opensolaris.org/os/community/on/crt/sponsor-tasks/ I work in Solaris sustaining with NFS and ZFS. Let me know what changes you're proposing and I can do local builds/test for you. -- Peter Blog: http://blogs.sun.com/peteh -- next part -- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature URL: http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20061127/0b229f7c/attachment.bin
[request-sponsor] 6494178 in.talkd should try harder to find a writeable tty
Hello, I created a patch for this RFE: http://www.loria.fr/~glisse/tmp/6494178.diff Basically the way in.talkd works is that it uses the first tty in utmpx that belongs to the right user. This tty may not be writeable. In this patch I modify the loop that looks for the first tty that belongs to the right user to make it find the first one that has the group write permission. I tried to make the patch as minor as possible to make it unlikely to break anything. There is already some code duplication between process.c and announce.c, and this slightly increases it. Refactoring the code would make for a cleaner solution, but it is more work, both to make and to review. An other solution would be for in.talkd to run as user talkd and group tty, this way a tty not being writable would probably make the current code try the next tty, but that is also more complicated than adding a simple stat (need to check exactly what privileges in.talkd needs) (besides, I tried modifying the manifest file, but in.talkd was still started root:root). I tested the patched in.talkd on S10U1 by simply substituting it to the original /usr/sbin/in.talkd (plus the appropriate svcadm disable/enable talk). When I talk a user who is not logged in, I get [Your party is not logged on]. When I talk a user whose ttys are all mesg y, it works. When I talk a user whose ttys are all mesg n, I get [Your party is refusing messages]. Now the only case that differs between the original version and mine: when I talk a user who has some ttys with mesg n and some with mesg y, my version always finds one of the mesg y ttys whereas the original one often answers refusing messages. I do not have a contributor agreement yet (currently trying to figure out who is supposed to sign it), I don't know if it is necessary for such a short patch. This message posted from opensolaris.org
[request-sponsor] 6494178 in.talkd should try harder to find a writeable tty
Hi Marc, A contributor agreement is needed for all contributions, regardless of size or complexity. If you are doing this yourself as an individual, you sign. If you are submitting something on behalf of your company, an executive from your company needs to sign. Let me know if you have more questions. Thanks. Bonnie Marc Glisse wrote: Hello, I created a patch for this RFE: http://www.loria.fr/~glisse/tmp/6494178.diff Basically the way in.talkd works is that it uses the first tty in utmpx that belongs to the right user. This tty may not be writeable. In this patch I modify the loop that looks for the first tty that belongs to the right user to make it find the first one that has the group write permission. I tried to make the patch as minor as possible to make it unlikely to break anything. There is already some code duplication between process.c and announce.c, and this slightly increases it. Refactoring the code would make for a cleaner solution, but it is more work, both to make and to review. An other solution would be for in.talkd to run as user talkd and group tty, this way a tty not being writable would probably make the current code try the next tty, but that is also more complicated than adding a simple stat (need to check exactly what privileges in.talkd needs) (besides, I tried modifying the manifest file, but in.talkd was still started root:root). I tested the patched in.talkd on S10U1 by simply substituting it to the original /usr/sbin/in.talkd (plus the appropriate svcadm disable/enable talk). When I talk a user who is not logged in, I get [Your party is not logged on]. When I talk a user whose ttys are all mesg y, it works. When I talk a user whose ttys are all mesg n, I get [Your party is refusing messages]. Now the only case that differs between the original version and mine: when I talk a user who has some ttys with mesg n and some with mesg y, my version always finds one of the mesg y ttys whereas the original one often answers refusing messages. I do not have a contributor agreement yet (currently trying to figure out who is supposed to sign it), I don't know if it is necessary for such a short patch. This message posted from opensolaris.org ___ request-sponsor mailing list request-sponsor at opensolaris.org
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
On Thursday, November 02, 2006 10:03:25 PM -0600 Mike Gerdts mgerdts at gmail.com wrote: However, sync(1m) could do the same check that sync(2) does and return the appropriate error. Ugh! No, thank you. I already see enough trouble with programs that think they know what the privilege model is and refuse to run if, say, the UID is not 0, or the mode on some file is not what that (ACL-unaware) program expects, or whatever. As a filesystem developer, I've seen the same problem with OS's whose VFS layer decides that the user won't be able to change some property of a file because his uid is not the same as the file's, and returns an error without ever bothering to pass the operation to the filesystem. Guessing whether you are allowed to do something and then not bothering to try if the answer is no will always come back to bite you, or someone. 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. If you print Permission Denied, it better be because some syscall return EPERM. Don't fake it. IMHO, it's better for sync(1m) to silently do nothing than to print a bogus error message for an operation it never tried. -- Jeffrey T. Hutzelman (N3NHS) jhutz+ at cmu.edu Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
