[shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
That said, its possible that the GNU tools will evolve in the future, at a rate differently than the ksh93 versions do. (At that point, the case says that the ksh93 version will either be adapted, or they'll stop supplying the built-in.) And, unfortunately, anyone who wants to deploy a newer version of a GNU tool in OpenSolaris needs to make sure that ksh93 is updated at the same time. Casper
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
Architecturally, I have to agree with Darren here. I don't know what the concerns are here where this would fail to operate with the current pfexec... I thought that it was just the case that pfexec would bypass the builtin and use the filesystem supplied binary. That is not currently the case and pfsh in OpenSolaris doesn't work as OpenSolaris did for the builtins. I'm hoping to fix that by making sure we ignore the builtin commands in profile shells. (By default and as only option inside of a profile shell) Casper
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
On 18/03/2010 16:38, Garrett D'Amore wrote: On 03/18/10 09:28 AM, Casper.Dik at Sun.COM wrote: Architecturally, I have to agree with Darren here. I don't know what the concerns are here where this would fail to operate with the current pfexec... I thought that it was just the case that pfexec would bypass the builtin and use the filesystem supplied binary. That is not currently the case and pfsh in OpenSolaris doesn't work as OpenSolaris did for the builtins. I'm hoping to fix that by making sure we ignore the builtin commands in profile shells. (By default and as only option inside of a profile shell) Casper This sounds like a showstopper for this case then. This case doesn't make the current situation worse. I also now understand that isn't really that relevant to this case anyway because this is all about when /usr/gnu/bin is first in your path and about providing builtins for that. Since we have no /usr/gnu/bin entries in exec_attr anyway there is no issue with pfexec and this case. I agree with Darren (assuming there are no profiles with now builtin GNU commands) Casper
[shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
the fix to disable builtins for pfksh is only a few lines dgk and I are checking out the code now there is another alternative if we can pfexec bracket sections of code inline I beleieve a message yesterday, about 1000 posts ago:) mentioned this is possible e.g., for the builtin b_mkdir() (with made-up function names) pfexec_pretend(mkdir) b_mkdir() pfexec_stop_pretending() if this is possible I would like to see example code No, not quite: the kernel-code will only work on exec and not inside a shell. Casper
[shell-discuss] open source sed [PSARC/2010/086 FastTrack timeout 03/17/2010]
The integration with ON isn't done, as far as I'm aware. Indeed; you will need to have a completely finished workspace were all you need to type is hg push. Then most of the work is done and you ask for a sponsor. Casper
[shell-discuss] open source sed [PSARC/2010/086 FastTrack timeout 03/17/2010]
Casper.Dik at sun.com wrote: The integration with ON isn't done, as far as I'm aware. Indeed; you will need to have a completely finished workspace were all you need to type is hg push. Then most of the work is done and you ask for a sponsor. Well, I asked many times for a documentation of the ON Buildsystem. I mentioned already, that the buildsystem looks like the only real problem. There is not a whole lot of documentation; clearly people have been able to integrate ksh93 into Solaris Nevada without such documentation. Part of it includes copy paste development and understanding how to build your own archives (running nightly), taking it from here: http://hub.opensolaris.org/bin/view/Main/get and then copy your own source, create Makefile, check them in and create your own code. Casper
Add Text Mode UI and Common Library to Device Driver Utility [PSARC/2009/602 FastTrack timeout 03/05/2010]
Bill Yan wrote: Has the project team been in contact with the pkg team to ensure that drivers installed using this tool won't be automatically removed from their installed locations during pkg image-update? If SVR4 packages are added and their files are orthogonal to IPS packages, then IPS will leave those files alone. DDU will use the pkg command to install IPS packages. Actually, SVR4 package files will be moved to lost+found by IPS image-update in some cases - this has bitten users with the SVR4 installed NVIDIA driver on a number of occasions, but I believe that's considered a bug in IPS, not a part of it's architectural design. Or any other files installed not by IPS. IPS also fails when you remove a file and IPS then tries to remove the package, at least during update-image. IPS should behave more like SVR4: if the directory is not empty, keep it. If a file was already removed, don't complain. Casper
RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010]
Only authorizations seem to be explicitly addressed here. How are executables addressed? That is the use of pfexec? Through the profiles. There are no defaults exec attributes listed in policy.conf. So you're saying that the pfexec search as well as the auth search stops at the Stop reserved Rights Profile name. That answers my question. Yes, correct. Casper
RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010]
This project proposes updates to the rbac implementation. Release binding: minor. The current rbac implementation has several shortcomings: The project team doesn't say why these are shortcomings. I was having a hard time getting the motivation. Fortunately in an offline discussion today, it was pointed out that the particular use model was for a kiosk user model and that the intent was to explicitly define specific user accounts that would be restricted as an exception to the architecture introduced when RBAC was introduced. Given that I too am happy with the case (+1), but have a few nits with the specification that I'd like acknowledged. - it's not easy to override the default privileges defined in /etc/security/policy.conf - every user *always* inherits whatever is specified in /etc/security/policy.conf: AUTHS_GRANTED, PROFS_GRANTED And the console owner gets the CONSOLE_USER. Currently you cannot make a pf*sh like a restricted shell. You get Basic Solaris User and also All. This is the reason why we have the stop profile: it removes the additional profiles, include all those listed in policy.conf (including, console_user). I allows a restricted shell without having to build a controlled directory. There is nothing inherent in this proposal that will stop getting other keywords. In particular audit_flags as specified in PSARC/2010/003, EOL and removal of audit_user(4) and getausernam(3bsm). Correct. Each and every keyword requires a similar amount of work: you do not get the others for free and that is why I have limited myself to these keywords. The new system defined profile Stop; when this profile is encountered it excludes all the later profiles which would normally be encountered. Specifically, if a user has a profile in its list which includes Stop, then the PROFS_GRANTED profiles are never considered for this user and the AUTHS_GRANTED are ignored. Additionally if the user is the console owner, the CONSOLE_USER profiles are never considered for this user. Only authorizations seem to be explicitly addressed here. How are executables addressed? That is the use of pfexec? Through the profiles. There are no defaults exec attributes listed in policy.conf. Casper
increase number of realtime signals [PSARC/2010/062 Self Review]
I. Szczesniak iszczesniak at gmail.com wrote: With the information in IEEE Std 1003.1(tm)-2008 I think the proposal is sound to use 32. It provides sufficient Linux compatibility and is inline with standards recommendations. Where is the ARC case which requires that Solaris defaults must match Linux defaults and not those from BSD or AIX? Without such a case this argument is invalid. Well, did you recently implement a BSD and AIX branded zone? The only reason for supporting the numbers from Linux seems to be brandz. I think it's also needed to support source code. Casper
PSARC/2010/069 - Solaris GUI Install Users Screen Modification
Since this case makes it mandatory that root is a role, it should also make it mandatory to assume the root role in order to get a root shell. The current behavior, whereby the user can get a root shell by typing pfexec bash is a serious security flaw, and is inconsistent with the RBAC implementation in Solaris. For example, such a sequence could be embedded in any script which the user might execute, thereby becoming root without the user's intent. So I agree with Darren that this case is incomplete, unless it also undoes the assignment of the Primary Administrator rights profile to the initial user. IMHO, it would never have been approved if it had been requested through the ARC process. Indeed; the new implementation of in-kernel pfexec makes this very clear; a user with a Primary Administrator as their profile, will get a root prompt when executing a pf*sh*. (That's because the in-kernel pfexec executes a profile shell as if it is executed by pfexec) Casper
RBAC update: user attrs from profiles [PSARC/2010/072 FastTrack timeout 03/03/2010]
Why just those two ? In general other than type I think all of the user_attr(4) keywords should be applicable in prof_attr (I wouldn't object to type being able to be specified in prof_attr though). In particular: roles, project, lock_after_retries but all the others too. For me project would be the most useful of those but I can see an need for the others too. Similarly the TX specific ones would be useful in prof_attr(4) for defining collections of users all with the same operating label range (min_label and clearance keywords). While I agree with assessment in principle, each and every additional keyword requires the same amount of additional code, so it's not free to add additional keywords. I want to implement these keywords first and then we'll have a discussion about the additional keywords and the market requirements. Casper
increase number of realtime signals [PSARC/2010/062 Self Review]
Good. But the RFE I filed asked to set the number of real time signals to 64 which does not require to change the definition of sigset_t. Indeed; it seems that the userland sigset_t is 128 bits large (but the kernel only uses 64) Casper
SPARC support for Fast Reboot [PSARC/2010/030 Self Review]
On 01/27/10 01:44 PM, Huay-Yong Wang wrote: I spoke to Chris and the case is amended for minor binding only. Chris will send out an update to the init(1M) manpage shortly. Thanks. Thanks for the clarification. I reaffirm my +1 (or 100). Same here. (Rebooting my SPARC systems often) Cas[er
SPARC support for Fast Reboot [PSARC/2010/030 Self Review]
I am sponsoring this fasttrack for Chris Kiick. This project implements fast reboot support for SPARC. Specifically, the -f and -p options in reboot(1M) is now supported on SPARC. Previously these options are only available for x86 platforms (See PSARC 2008/382 Fast Reboot) Note that the -e option (boot environments) is not yet supported on SPARC. This project introduces no new interface and I believe this qualify as self-review. I will be marking the case closed approved automatic. If anyone feels that this need to be promoted to a fast track please let me know. +1 Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
This case was approved at the 6 Jan PSAR Cmeeting. During discussion and code review, the definition of NET_ACCESS was changed to: privilege NET_ACCESS Allows a process to open a TCP, UDP, SDP or SCTP network endpoint. We also decided that the privileges documentation should more clearly point out that removing a basic privilege from any set leaves a process in a non-standard compliant state, may case unexpected application failures and should only be done with full knowledge of the potential side effects. Casper
Improving the use and debugging of the basic privilege set. [PSARC/2009/686 FastTrack timeout 01/01/2010]
This case was approved at today's PSARC meeting. Casper
pcmcia stuff.... it can probably simpler...
On 6/01/2010 5:44 PM, Garrett D'Amore wrote: .. Several folks have asked me about just nuking pcmcia altogether. I personally don't think this is viable for several reasons: 1) CompactFlash adapters -- CF is still used in some cases, though there are cheap USB readers Indeed. The PCMCIA CompactFlash adapter has a form factor that USB readers cannot match: it usually slides right into the laptop and leaves nothing protruding. The performance of the USB solutions isn't stellar but I'm not sure how fast the PCMCIA solution is. (CompactFlash currently supports speeds upto 90-120MB/s (B for bytes) and it's by far the fastest camera memory) Casper
pcmcia stuff.... it can probably simpler...
Yeah, everyone uses USB for this stuff mostly these days, and SDcard is a lot more prevalent. (CF mostly lost the format wars, despite being simpler, and in many ways faster. I think the physical form factor -- which is inappropriate for mobile devices like phones -- is probably what killed it in the long run.) It will take SDXC before it has sufficient capacity and sufficient bandwidth before it will find itself in the more expensive cameras (e.g., the Canon 1D/5D/7D: these will write upto 64MB/s (or more) when shooting jpegs) So would you complain if pcata were to go away? Can you use a USB based CF reader on said laptop (or perhaps a cardbus version, which would fit in the same slot, and be a lot faster?) I've no problem now that I've learned that it is so slow. Beside, pcfs is so slow that it doesn't perhaps matter all that much. I also have a pcwl (Orinoco Gold) card that I use on my laptop occasionally because the built-in interfaces tend to stink royally. Yeah, I think there are still a lot of folks using pcwl. Which is kinda unfortunate because the driver lacks some important workarounds/fixes for some errata. (Which mostly hurt the miniPCI version of pcwl badly enough that I consider miniPCI Prism 2.5 cards to be completely unusable with the pcwl driver. At one point I was going to try to fix this, but I've since mostly lost interest since I don't use my one laptop that had one of these cards anymore -- it was a Tadpole SPARCLE) I started to use pcan and later I got an Orinoco; both were fine (I actually made pcan work on the PCMCIA slot in the sbus card) The question is really one of: what do you want to gain by removing this feature? Casper
EOF elxl [PSARC/2010/005 FastTrack timeout 12/12/2010]
James Carlson wrote: Garrett D'Amore wrote: 1) No support for automatic link negotation/reporting. This means it won't work with nwam. 2) No support for full MTU vlans. 3) Closed source. None of those things matter for the existing users. ;-} nwam will start to matter when we switch to using network/physical:nwam by default. It is strange because an earlier driver *did* properly proper full/duplex but this was removed at some time. Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
We have room on the agenda this week and we could simply have a verbal conversation to bring this fast-track to convergence without necessarily derailing it. I think such a discussion would be most productive if Casper, Erik, and Meem could attend. Would that be possible? Ok, that'll work for me. Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
I'm starting to think a derail might be in order, but I'd like to know how the other members feel. I'm neither the foremost security nor the foremost networking member of PSARC, so I'll just defer to the decision(s) made by those individuals. I still haven't seen any application which uses inet sockets and which isn't a system tool; even the X server can work without tcp sockets. In theory, I can see that this might be an issue, but note that an application with one or more basic privileges missing is no longer running in a POSIX environment. It is similar to the FILE_READ and the FILE_WRITE privileges: a file cannot open a file for read or write. I want to clarify the definition of the NET_ACCESS privilege as follows: privilege NET_ACCESS Allows a process to open a TCP, UDP or SCTP network endpoint. This makes clear that ICMP and RAW sockets do not require more than the NET_ICMPACCESS or NET_RAWACCESS. While I'm not against derailing, per se. I will understand that a fine grained access control may serve all users better and we are actually working on that. This is a simple mechanism and similar mechanisms have been tested by customers, using artifacts of earlier Solaris implementation. These artifacts no longer exist and so the customer has a problem. In theory, this might not be the best but in practice it seems to work well. Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
John Plocher wrote: What is the basic use case for this priv? I assumed it was to let setuid programs have one more thing they could give up, to reduce the number of things an exploit could do if you did find a security hole in them that allowed running arbitrary code, like most of the rest of the basic privileges. It is also possible to contain users in a can't break out shell; they can run their application but they cannot copy data outside of the machine. In Solaris 8 you can get this functionality by adding an ACL to /dev/tcp; I think the difference is that for those, the set of system middleware we provide doesn't silently rely on them for proper operation; Just various non-obvious functions in libc(). (Do you think most programmers realize wordexp(), pututxline() or grantpt() call fork+exec?) Absolutely; I think, though, that grantpt() no longer calls exec: pt_chmod is gone (or is it now running devfsadm). Having testing the net_access privilege, I can say that few library calls use AF_INET sockets for IPC. Note that localhost RPC will not use AF_INET; name service lookups will use sockets but you nscd will do it for you. With cscope, I wasn't able to find a library routine which uses networking as IPC without clearly being a network function. But even such interface exists, I don't believe that that is fatal to this proposal; similarly to issues with wordexp(), pututxline(), grantpt(). Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
[1] Loopback inet IPC is actually a fairly useful beast since it allows cooperating applications to rendezvous without requiring a writable fileystem. Much of our stack uses loopback RPC and this works fine; loopback inet is more difficult to use, particularly because it requires a well-known port. I would love to see an example of current use of AF_INET loopback as an IPC mechanism. Note also that we try to make sure that non of the internal IPC mechanisms don't listen to the world; AF_INET isn't the easiest way to achieve that) Note that the current RFE 6434380 was initially filed for both network and IPC; but since there are so many way to construct local IPC, e.g., using a mmap'ed queue, there seems to be no easy way to enforce this. Casper
Improving the use and debugging of the basic privilege set. [PSARC/2009/686 FastTrack timeout 01/01/2010]
Darren J Moffat wrote: Casper Dik wrote: The new debugging functionality is implement as follows: The priv_debug kernel variable is initialized to 1 on DEBUG kernels. When priv_debug is non zero when the system boots, a new privilege is allocated and it is added to the basic set. The new privilege is called basic_test. This makes sense as a debug functionality. Given this is for debug I don't actually think an ARC case was required unless the intent is to document this. So I'm happy to give this a +1. I assume that we would document priv_basicset(). This is why I put the difference to the manual page in the fasttrack. Casper --- priv_addset.3 Mon Dec 21 12:08:24 2009 +++ priv_addset.3.new Mon Dec 21 12:10:00 2009 @@ -20,6 +20,8 @@ void priv_emptyset(priv_set_t *sp); + void priv_basicset(priv_set_t *sp); + void priv_fillset(priv_set_t *sp); void priv_freeset(priv_set_t *sp); @@ -58,6 +60,8 @@ The priv_emptyset() function clears all privileges from sp. + The priv_basicset() function copies the basic privilege set to sp. + The priv_fillset() function asserts all privileges in sp, includ- ing the privileges not currently defined in the system.
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
I know of at least one customer who used to accomplish this in previous Solaris releases by restricting the permission bits on /dev/tcp. [1] It's worth re-examining Meem's objection about IPC in light of customers like this. When this basic privilege is available, they might well remove it from all user processes in order to get the same effect they had before. How much IPC breakage is likely to follow from this action? My experience is that there is very little, if any, breakage. [1] This technique doesn't work any more because socket() operations do not open /dev/tcp. In Solaris 10, we still open evaluate the device policy; but in Volo, we never get near to /dev/tcp. Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
But it makes the description of NET_ACCESS much more complicated; not only do we have PRIV_NET_RAWACCESS but also PRIV_NET_ICMPACCESS. I'm not sure that this more complicated by any stretch of imagination. + PRIV_NET_ACCESS + Allows a process to open an unprivileged network connection. + If we uniformly apply NET_ACCESS for all IP based transports then there is a single privilege that needs to be removed to ensure that IP networking can not be used. Requiring multiple privileges for a specific operation runs against the grain of the Solaris privilege implementation. Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
I would love to see an example of current use of AF_INET loopback as an IPC mechanism. Both in.mpathd and dhcpagent use this mechanism. Of course, they are both networking daemons, but the IPC channel has nothing to do with them being networking daemons. Right, but neither are applications, rather they're system tools. I was thinking more of a application or a library. Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
X-Mailer: VM 7.19 under 21.4 (patch 21) Educational Television XEmacs Lucid Reply-To: peter.memishian at sun.com FCC: MAILED Further to what Seb said, in general, loopback sockets are treated as an IPC mechanism and may be used by any random set of applications that have no interest in actually using the network. That is, not having the proposed NET_ACCESS privilege may cause random applications to fail even though they never attempted to access the network. Is this really the desired behavior? Yes. I wouldn't call it random; they're still INET sockets. The use is limited and specific for containing users. Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
I don't understand the motivation for excluding the raw sockets and/or
icmp sockets from checking NET_ACCESS. It seems simpler from a user
perspective if removing NET_ACCESS has the effect of making the user no
longer be able to open any TCP, UDP, SCTP, or RAW sockets.
Because you already need a privilege and there's no need to remove those
privileges?
Thus I think it makes sense removing the above exception.
Do we know if there is any impact to getaddrinfo() and friends? I
believe the library code opens a UDP socket to issue SIOC ioctls (done
as part of verifying whether IPv4 and/or IPv6 is configured on the
system). Perhaps that isn't an architectural issue, but we need to make
sure there aren't any confusing failures or error messages when
NET_ACCESS has been removed from the privilege set.
If the library detects that opening /dev/udp{,6} fails it will pretend that
there are IP/IP6 interfaces and the application will find the hostname but
won't be able to connect.
Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
Further to what Seb said, in general, loopback sockets are treated as an IPC mechanism and may be used by any random set of applications that have no interest in actually using the network. That is, not having the proposed NET_ACCESS privilege may cause random applications to fail even though they never attempted to access the network. Is this really the desired behavior? Yes. I wouldn't call it random; they're still INET sockets. They are inet sockets as an IPC mechanism that has nothing to do with networking per se. Same with AF_UNIX sockets. That is, this privilege will both prevent use of the network and prevent applications that happen to use loopback and AF_UNIX sockets for IPC from working. We have no control over what applications those may be. Why would this affect AF_UNIX sockets? In the case of loopback IPC: we do not support a system with lo0 unplumbed because we do not know what applications will break. This proposal seems to result in a system that is at least as unsupportable. No, because it is a basic privilege and so all applications will have the basic privileges unless they want to run without them. It is similar to all the other basic privileges: we can't tell whether an ordinary applications will or will not work without a specific basic privilege. The basic privileges have added a new class of users, subusers. You can use it to contain applications (can't call home) or users (can't squirrel data away on the Internet). When removing a basic privilege, the onus is on the administrator to determine that it will work for the particular user. Follow on projects will allow us to select what INET connections can be made; I do not believe that a carte blanche for localhost connections is warranted: it allows sending email out through sendmail using the submission port. Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
Casper Dik wrote: This project proposes one new basic privilege. NET_ACCESS Allows a process to open a network connection. Looks pretty reasonable to me, though you may want to reconsider the timeout. The fast-track running period is mostly occupied by the holiday break. Changed the timeout to 01/06/2010. Casper
Improving the use and debugging of the basic privilege set. [PSARC/2009/686 FastTrack timeout 01/01/2010]
Changed the timeout to 01/06/2010 Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
On Tue, 2009-12-22 at 06:26 -0800, Casper Dik wrote: This project proposes one new basic privilege. NET_ACCESS Allows a process to open a network connection. The purpose of this privilege is the ability to create a process confined to the current system. Semantic nit: This mechanism accomplishes that and more. For example, without this privilege, a process also cannot open a PF_INET* socket to communicate locally using the loopback address. I assume that this is an acceptable situation for the intended consumer, otherwise one would need some more complex mechanism (perhaps involving the proposed socket filter framework PSARC 2009/590). True; however, we have sufficient local transport available and we also have nscd; no need for ordinary applications to directly call the NIS/LDAP/ DNS server. Casper
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
Right, and I think you may also have discovered libnsl's use of socket ioctls to get local address information while processing name lookup calls. It does that because nscd's address lists are unsorted, and getaddrinfo() and friends return a sorted address list using an algorithm that uses the local address list as input (this was introduced by PSARC 2002/390). That said, given that applications without the proposed privilege won't be able to communicate with the returned addresses, their sort order is quite meaningless. In that case, ignoring the failed socket() call and returning the unsorted address list directly from nscd would likely be the right thing to do. I indeed discovered this; I do prefer fixing that, though, because I prefer this: finger @localhost [localhost] socket: Permission denied to this: finger @localhost unknown host: localhost So why is nscd not sorting the addresses? In any case, +1 from me. Thanks. Casper
delete obsolete system call traps [PSARC/2009/657]
Is there any other benefit only achieved by removing those from the sysent table? If not, my preference would be to leave 'open' and friends alone for now, resolving that with kernel function calls instead. If we reach the point of needing the additional slot entries freed up by those, that work can be done along with a true man(2)- equivalent syscall provider. Will this not also disable SunOS 4 binary compatibility? I seem to remember that the binary compatibility runs some old system calls before it starts calling the kernel through the native libraries? Casper
delete obsolete system call traps [PSARC/2009/657]
I rebuilt /usr/lib/ld.so (the 4.x dynamic linker) so it works correctly with the modified system call traps. Also the libbc stuff and /usr/4lib/sbcp There is no problem with 4.x binary compatibility. Thanks Roger. Casper
pfiles offset [PSARC/2009/625 FastTrack timeout 11/20/2009]
Also, it'd be nice to have stable pfiles output. That would definitely require escaping some filename whitespace, but I know, that's not this case. Still, I wouldn't be surprised to see scripts built around pfiles, in which case adding offset to the lines that starts with fildes numbers is probably best (since there items are already comma-separated). Something like having a -p option (like kstat) and a -o this,and,that like ps? E.g., the standard is: 11852: tcsh Current rlimit: 256 file descriptors 0: S_IFCHR mode:0666 dev:413,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDONLY|O_LARGEFILE /devices/pseudo/mm at 0:null 1: S_IFCHR mode:0666 dev:413,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDONLY|O_LARGEFILE /devices/pseudo/mm at 0:null 2: S_IFCHR mode:0666 dev:413,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDONLY|O_LARGEFILE /devices/pseudo/mm at 0:null 15: S_IFCHR mode:0600 dev:414,0 ino:66879962 uid:21782 gid:7 rdev:24,2 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/2 16: S_IFCHR mode:0600 dev:414,0 ino:66879962 uid:21782 gid:7 rdev:24,2 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/2 17: S_IFCHR mode:0600 dev:414,0 ino:66879962 uid:21782 gid:7 rdev:24,2 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/2 18: S_IFCHR mode:0600 dev:414,0 ino:66879962 uid:21782 gid:7 rdev:24,2 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/2 19: S_IFCHR mode:0600 dev:414,0 ino:66879962 uid:21782 gid:7 rdev:24,2 O_RDWR|O_LARGEFILE FD_CLOEXEC /dev/pts/2 and pfiles -p would produce: 11852 0 c r-- /dev/null or some such? Casper
ZFS Deduplication Properties [PSARC/2009/571 FastTrack timeout 10/21/2009]
1. don't allow fletcher2,verify. (we only allow checksum=fletcher2 for backwards compatability anyway) I think you'll see this was called out explicitly in section B.1. Is fletcher2 still the default? The zfs manual claims that. Casper
Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009]
I've heard this affects NFS when using AUTH_SYS (still common). What impact will be seen there? Here's a blog with a good description of the NFS problem: http://nfsworld.blogspot.com/2005/03/whats-deal-on-16-group-id-limitation.html It is listed in the case materials; the current Solaris kernel will drop any RPC operation where the user is in more than 16 groups. Other implementations will just truncate the number of groups to 16. I'm inclined to follow the market, truncate the group list and then try the RPC operation. It's in the specification. Specifically, I was convinced when I was running with 1000 groups and I was not able to access anything over NFS. Not very practical. Casper
Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009]
It depends If you use the withdrawn POSIX ACL draft, then by truncating the list you will potentially get less permissions. If you use NTFS ACLs that include deny entries this differs. As we are talking about older NFS versions that do not support NTFS ACLs, it seems to be not a security risk to truncate the list. Well, it could be. You're in groups 0 .. 16 (17 total) There's a file in group 16, mode rwrw-. However, AUTH_SYS is a security risk in itself and it's easy to fake any group list or uid. Adding a small security issue to a gaping hole isn't worth losing sleep over. The only other issue is that truncating may cause unexplained permission issues. However, not truncating the gid list requires the administrator to give all users at most 16 groups or they won't be able to use NFS. Casper
EOF of libucb [PSARC/2009/541 OnePager]
The title seems slightly misnamed. This isn't just libucb; isn't it really the removal of SunOS 4 binary compatibility? Correct; the SUNWbcp package (SunOS 4.x Binary Compatibity) uses these libraries. Are these libraries listed in the SPARC ABI? Just removing the compile symlinks I have no issue with, but removing these libraries themselves also requires the removal of SunOS 4.x Binary Compatibility. Casper
EOF of libucb [PSARC/2009/541 OnePager]
Actually, looking at the code, I don't see how /usr/ucblib is used by 4.x *binaries*. I.e. if you have a SunOS 4.x binary, it looks like you get the libraries in /usr/4lib, using the a.out exec module. I don't think you wind up using any of the ELF stuff in /usr/ucblib. dump -Lv /usr/4lib/sbcp DYNAMIC SECTION INFORMATION .dynamic: [INDEX] Tag Value [1] NEEDED libmapmalloc.so.1 [2] NEEDED libc.so.1.9 [3] NEEDED libucb.so.1 [4] NEEDED libnsl.so.1 [5] NEEDED libc.so.1 [6] RUNPATH /usr/4lib:/usr/ucblib [7] RPATH /usr/4lib:/usr/ucblib (sbcp is for Static Binary Compatibility; however, it's easy to have a partially statically linked executable so I think sbcp is always loaded for an a.out executable) Also, /usr/4lib/libc.so.1.9 is linked to libucb.so.1. So, maybe I didn't name this inappropriately after all. What *would* break, are 4.x *sources* that have been *compiled* on SunOS 5.x. And 4.x binary compatibility :-) Casper
EOF of libucb [PSARC/2009/541 OnePager]
It's quite possible that this is all just a vain effort to tilt at windmills, but I at least wanted to have the *discussion*. This seemed like a rare opportunity to have such a discussion. If we deliver Solaris.next with these components, then its likely that another opportunity to discuss it might not come along for a *long* time. True; certainly I think that we should minimally remove the symbolic links and the headers. I think we've added most of the stuff missing in libc finally (alphasort, scandir) Casper
Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009]
Ucred routines will shrink the actual size of the ucred exchanges: the ucred structures will shrink to fit and only processes which use a lot of groups will pay for this in ucred exchanges. How does this work? The size of a ucred is not passed around, but required to be ucred_size(3C). I guess receiving code will malloc() ucred_size() bytes, receive the ucred, and realloc() to the correct, smaller size, which would be encoded in a ucred header. Or perhaps you'll be enhancing the ucredsys/doorsys syscalls so that you only alloc as much as needed? Yes, implementation details, I know. But interesting details nonetheless. Ucred is currently formatted like this: headerpcred_tNGROUPS_MAX * gid_tprivs[audit][txlabel] The new generated format is: headerpcred_tcr-cr_ngroups * gid_tprivs[audit][txlabel] Well, you can't know how big the item you are going to receive and you want to be able to re-use the buffer. (With 1024 groups, you'll need to allocate at least 4K)So in userland you allocate ucred_size(). In the kernel we generate the ucred and we know how big the item is going to be; we allocate as much as we need and we copyout just that data. Casper
Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009]
This project proposes changing the maximum value for NGROUPS_MAX from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 to 1024. NGROUPS_MAX as defined by different Unix versions are as follows (http://www.j3e.de/ngroups.html): Linux Kernel = 2.6.3 65536 Just a note: a (possibly future) change above INT16_MAX will require fixing ON audit code that assumes the maximum number of groups is a short -- this would need to be changed to ushort. I found that bit of code; more is needed, specifically adding so much data to a cred without using it. +1 Thanks, Casper
Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009]
Gary Winiger wrote: This project proposes changing the maximum value for NGROUPS_MAX from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 to 1024. NGROUPS_MAX as defined by different Unix versions are as follows (http://www.j3e.de/ngroups.html): Linux Kernel = 2.6.3 65536 Just a note: a (possibly future) change above INT16_MAX will require fixing ON audit code that assumes the maximum number of groups is a short -- this would need to be changed to ushort. +1 Gary.. Is there a reason to not go to 32K right away? I think that would require quite different algorithms to scale to that point; as there is a push to do a back-port, I prefer to keep the algorithms the same. I'm removing NGROUPS_UMAX for all the userland code so a later change would be simpler in that no work outside the kernel is needed. Casper
EOF of libucb [PSARC/2009/541 OnePager]
readdir()- Different implementations, but apparently identical semantics and structures. Could probably be eliminated. Nope, /usr/ucbinclude/sys/dir.h vs dirent.h re_comp() re_exec()- These are backed by nearly identical sources, with just some stylistic and lint fixes (e.g. substituting 0 for NULL and casting). Could be eliminated. scandir() alphasort()- Nearly identical implementations, and identical semantics. Could be eliminated. See readdir. You're missing signal (different semantics) Issues with alloc (worst problem to debug at the time was that SunOS malloc uses the buddy allocator and it was very forgiving. Standard Solaris wasn't so forgiving. (But we have much better tools now) Casper
Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009]
On Mon, Sep 28, 2009 at 05:28:09PM +0100, Darren J Moffat wrote: Why isn't the implementation of this using the port_associate(3C) facility to watch for the default timezone file being updated ? [Not the i-team] Probably because that would mean having a thread to wait in port_get(3C). That seems too heavyweight to me. I'd love to see something asynchronous, like a signal or AST for this. Or perhaps because that mechanism requires an open file descriptor *and* it requires to poll the port or add a thread. And fds cached in library routines have issues with being closed by programs. (An mmap'ed object would not have that issue) Casper
Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009]
Casper.Dik at Sun.COM wrote: Now that we have this large mechanism to update the timezone information, I'm missing a number of things: it appears not to be possible to change the timezone dynamically; there are customers who want this. In the initial implementation of Olson's code uses a link called localtime and with a broadcast mechanism we could have this function pretty much for free; should this not be added to this project? It is possible if timezone is not supplied by TZ env variable. localtime() will reload /etc/default/init as well. If timezone is supplied by TZ env variable, localtime approach is needed. Currently localtime isn't read by default, but it is out of scope of this project. Except that localtime *may* read /etc/default/init but by default it will NOT because all processes have $TZ set from the boot time /etc/default/init. You can get that in two ways: use localtime or not set $TZ for all processes; as setting $TZ is a optimization. So perhaps that's a better solution: do not set $TZ in the environment. Using Olson's code can change the timezone dynamically, but only for processes which were restarted or started after the file is changed. Active processes which have loaded localtime never reloads the file. how is the semaphore checked and why is a mmap file in, say, /var/run not good for this purpose? If the file can be truncated, it could potentially send SIGSEGV to all active processes that calls ctime(3C). By root, right? Root can also truncate /lib/libc.so.1 so that doesn't fly. Casper
Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009]
how is the semaphore checked and why is a mmap file in, say, /var/run not good for this purpose? If the file can be truncated, it could potentially send SIGSEGV to all active processes that calls ctime(3C). Abort from that I don't properly think we need to code truncated root owned files, like libc, there are some outs: - non-faulting loads (only for SPARC??) - mincore(address, pagesize(), bit) Casper
Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009]
You can still use TZ=localtime and make a localtime link under the zoneinfo dir, but I agree that reading localtime by default would be nice to have for those people who would like to change the timezone dynamically. It would be nice if localtime pointed to a fixed location and that that fixed location (e.g., /var/init/localtime) and make that function point to somewhere in /usr/share/lib/zoneinfo so that /usr remain mostly read-only. how is the semaphore checked and why is a mmap file in, say, /var/run not good for this purpose? If the file can be truncated, it could potentially send SIGSEGV to all active processes that calls ctime(3C). By root, right? Root can also truncate /lib/libc.so.1 so that doesn't fly. Yes. But libc.so.1 would be an extreme example. We thought that such file/memory page needs to be protected in certain degree to avoid catastrophic result. If that's a regular file someone(has root privilege) may carelessly truncate it or unlink and re-create it. We just wanted to minimize those risks. If we shouldn't worry about those, I'll revise the spec to use a regular file. I wouldn't see how that could happen other then, say, truncating /bin/cat. You could measure how expensive mincore() is (it's seems about 0.5-1.0us per call which is possibly a bit too much for each time call) but I think it is not needed. Of course, if other folks think that the original proposal is a proper heavy weight mechanism, please let them speak up. Casper
Timezone cache renewal [PSARC/2009/516 FastTrack timeout 10/02/2009]
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Timezone cache renewal 1.2. Name of Document Author/Supplier: Author: Nobutomo Nakano 1.3 Date of This Document: 25 September, 2009 4. Technical Description Name Timezone cache renewal in ctime(3C) (aka No reboot on timezone update) Background -- Timezone patches contain the updates of the zoneinfo database files. Internally libc caches the timezone information and never rereads it. This means that when the timezone patches are applied and updates are made to the zoneinfo database, files they are not activated until the system is rebooted or the various process that use the timezone information are restarted. The impact of a reboot for the changes in the timezone is significant especially for those customers with many Sun servers running many domains. Now that we have this large mechanism to update the timezone information, I'm missing a number of things: it appears not to be possible to change the timezone dynamically; there are customers who want this. In the initial implementation of Olson's code uses a link called localtime and with a broadcast mechanism we could have this function pretty much for free; should this not be added to this project? how is the semaphore checked and why is a mmap file in, say, /var/run not good for this purpose? Casper
fragmentation controls for ping and traceroute [PSARC/2009/515 FastTrack timeout 10/02/2009]
On Fri, 2009-09-25 at 14:57 -0700, Erik Nordmark wrote: Sebastien Roy wrote: This sounds wrong. If you set the don't fragment bit then you ARE doing path MTU discovery. I think we only do this on TCP/IP and we don't do this for ICMP (ping) or UDP (traceroute). That's also a typo, it should say Turn on path MTU discovery. It doesn't quite do that, since using path MTU discovery with ping or traceroute would mean to most people that ping and traceroute would report the path MTU it discovers (there versions of traceroute out there that do just that). Hence my suggestion to say Turn off fragmentation. That sounds fine to me. +1 (the case and the clarifications) Casper
fragmentation controls for ping and traceroute [PSARC/2009/515 FastTrack timeout 10/02/2009]
I'm submitting this fast-track for Erik Nordmark, it times out on 10/02/2009. The release binding is Patch. Background: -- Since Solaris 2.0 we have enabled path MTU discovery by default including for UDP and RAWIP sockets. The addition of IP_DONTFRAG [PSARC/2009/494] allows applications to control this. Solaris implements traceroute -F (dontfrag) to disable path MTU discovery for traceroute. But this is documented as not working in zones. And the implementation doesn't do it for IPv6 at all. BSD implements a -D option to ping(1m) to enable path MTU discovery just like -F does it for traceroute. Solaris does not currently implement this option. Details: --- This case is to introduce ping -D in Solaris and remove the limitations for traceroute -F.. The behavior of ping and traceroute when these options (-D and -F respectively) are not specified is unchanged. Exported Interfaces - Interface Classification Comments - ping -D option Committed ping(1M) ping -F option Committed traceroute(1M) - traceroute -F option, surely? Man page updates: Add this text to ping(1M): -D Turn off path MTU discovery. For IPv4 this means setting the Don't Fragment bit. For IPv4 and IPv6 this means to not allow fragmentation as the datagrams are sent. If the data_size exceeds the MTU, then ping may report that sending failed due to Message too long. Change the text in traceroute(1M) from: -F Set the don't fragment bit. This option is valid only on IPv4. When specified from within a shared-IP zone, this option has no effect as the don't fragment bit is always set in this case. to: -F Turn off path MTU discovery. For IPv4 this means setting the Don't Fragment bit. For IPv4 and IPv6 this means to not allow fragmentation as the datagrams are sent. If the packetlen exceeds the MTU, then traceroute may report that sending failed due to Message too long. --- This sounds wrong. If you set the don't fragment bit then you ARE doing path MTU discovery. I think we only do this on TCP/IP and we don't do this for ICMP (ping) or UDP (traceroute). Casper
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
I suppose at one point having those headers on the system was useful for debugging back when people had to manually work out structures in adb. These days with CTF they are completely unnecessary. Whenever I easily I can, I remove project private (especially *driver private!*) headers from packaging. There's still: pidentd, lsof. Casper
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
Incidentally, Linux has its own list API, including inlined functions. It'd be nice to have compatibility with that. Also, I second Darren's sentiment w.r.t. the AVL tree API. Inlining is not much different from macro's. I've used the AVL lists for the Turbo charged SVR4 packages and they work really well and they're about as quick appending to a linked list. (SQL was clearly not properly suited for handling a very simple database) Casper
PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009]
One of the major consumers of the lbolt service are the cv_timedwait() and cv_timedwait_sig() routines, which require lbolt to form one of its arguments (an absolute value of time) and once again internally to decompose it into a relative time. This project is introducing two new routines, cv_reltimedwait() and cv_reltimedwait_sig() which will perform the same service of the previously mentioned routines but simply receiving a relative time, and not requiring lbolt at all. These new routines will also have a new argument of type time_res_t to inform the underlying timeout system as to how accurately the given timeout must expire. This will allow the kernel to anticipate or defer such timeouts when possible, allowing the system to stay idle for longer periods of time. In the Solaris kernel at this time, each user visible timeout (poll, timers) need to wait for at least 2 clock ticks as the kernel doesn't know when the last tick occurred. Will this new implementation allow for shorter timeouts and more precise timeouts? The minimum time waited should be around one clock tick and not a lot less; some applications expect that the kernel will wait for exactly one clock tick, even though they ask the kernel to wait for 1 microsecond. Casper
PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009]
Actually, I could really use the ability to use a timer based service that had a smaller window than 10 msec. For example, many audio devices have crummy interrupt capabilities... its a lot nicer (smoother audio) if I have a reliable way to get a periodic running at smaller intervals. (5 to 10 msec, but with precision -- the current stuff is simply too coarse.) This would simplify a lot of audio device drivers. And make them more robust as well. :-) Do they work better if you set hz to 1000? (hires_tick)? I remember that some devices failed to work when you set hz to 1000 such as the audio in the Ultra 45 (since fixed) but this was because of bad code. If your driver wants to sleep a short amount of time AND that time is less then 10ms, that code is hardly ever tested. (We should vet all the uses of drv_usectohz() and more sure that the argument is at least 1 or that we have an actual reason that we might want to sleep less) Casper
PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009]
The new callout implementation (CR 6565503 and others thru 6789031) fixes these problems. poll(10 msec) returns in 10 msec. The minimum timeout is still one tick, so to get shorter timeouts, you must set hires_tick. Just to be really sure: poll(10ms) now returns in 10ms and NOT in the interval [10ms .. 20ms)? Casper
PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009]
In those cases, we probably *could* just bump the timer up to 1000 usec, but wouldn't it be easier to just verify with tick = 1000? Fair enough, but it is clear that not every does this when developing kernels; perhaps the debug kernel must default to a 1000Hz tick? Casper
2009/470 tcp_keepalive For inetd Services
On Fri, Aug 28, 2009 at 11:12:37PM +0100, Andrew Gabriel wrote: This is quite different from any of the existing inetd configuration parameters - inetd doesn't currently allow manipulation of socket configuration parameters. But maybe it should. There's a large variety of potentially useful socket options to use, including IP_SEC_OPT (on listening sockets). I concur. I wrote a prototype for the following setsockoptions: - SOL_SOCKET, SO_KEEPALIVE, Boolean - SOL_SOCKET, SO_RCVBUF, Integer - SOL_SOCKET, SO_SNDBUF, Integer - SOL_SOCKET, SO_ALLZONES, Boolean - SOL_SOCKET, SO_RECVUCRED, Boolean - SOL_SOCKET, SO_TIMESTAMP, Boolean - SOL_SOCKET, SO_REUSEADDR, Boolean (already implemented: fixed as true) - IPPROTO_IP, IP_RECVDSTADDR, Boolean - IPPROTO_IP, IP_RECVOPTS, Boolean - IPPROTO_IP, IP_RECVIF, Boolean - IPPROTO_IP, IP_RECVSLLA, Boolean - IPPROTO_IP, IP_RECVTTL, Boolean - IPPROTO_IPV6, IPV6_RECVPKTINFO, Boolean - IPPROTO_IPV6, IPV6_RECVTCLASS, Boolean - IPPROTO_IPV6, IPV6_RECVPATHMTU, Boolean - IPPROTO_IPV6, IPV6_RECVHOPLIMIT, Boolean - IPPROTO_IPV6, IPV6_RECVHOPOPTS, Boolean - IPPROTO_IPV6, IPV6_RECVDSTOPTS, Boolean - IPPROTO_IPV6, IPV6_RECVRTHDR, Boolean - IPPROTO_IPV6, IPV6_RECVRTHDRDSTOPTS, Boolean - IPPROTO_IPV6, IPV6_V6ONLY, Boolean (already implemented) As with all keepalives this is to... keep idle connections alive. And to detect broken connections. If the client goes away, the server wants to tear down the sessions. Casper
[desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager]
Correct. The way the code works is that it calls fgetpwent() and if /etc/passwd contains no value, then that account does not show up in the Face Browser. So, users would need to avoid using the shorthand if they want the user to show up in the GDM Face Browser. If that is inappropriate, then we could change the logic to work a different way. I would suggest that that is a bug. Casper
Fast Crash Dump [PSARC/2009/330 FastTrack timeout 08/18/2009]
Ivek Szczesniak wrote: The stdio implementation in libc is among the slowest stdio versions out there. If you want to archive better performance you should use the stdio implementation in libast or use mmap(2). This is an interesting implementation suggestion, but is outside the scope of PSARC because it does not affect the interfaces being proposed. We did achieve quite a speedup over the old method. We'll take another look. Using libast might well incur extra PSARC oversight -- are the libast interfaces public? Consolidation private? If they are *project private* then you'll need to get a contract for them. Using mmap() would be free of those issues, and is likely to be the fastest without imposing any new interdependencies. I would suggest that you first measure before using libast. Typical, actual I/O operations takes a lot of time and the ineffective fread implementation time waste wouldn't be measurable. Casper
SECURITY: request for feedback/review of asadmin command authentication
The v3 stop-domain command needs to execute the command on the server (as opposed to using kill or something like that), which means it needs to authenticate with the server. To allow v3 to be more compatible with v2, we're considering adding a new authentication mechanism that will only work in the local case. Roughly, here's how this would work... On server startup, the server would generate a large random number and write it in a file that is readable only by the owner of the file (the user who started the server). Local commands, such as stop-domain, would read this file if it's available and send the number as part of the authentication information to the server. The server would accept either the normal username/password authentication, or some special username along with this number as the password. In Solaris it's easy to know which user is on the other end of a local connection. Why not use that information instead? Casper
GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager]
nobody:x:60001:60001:NFS Anonymous Access User:/: noaccess:x:60002:60002:No Access User:/: nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: Since these users do not have valid shells specified, these would not be shown. These actually have a valid shell (the default shell, /bin/sh, is used when the password shell lists the empty string for the shell). Can gdm determine which users are locked? Does gdm read /etc/passwd directly (to find out the local accounts?) Or does gdm use getent()? (This lists all users in files, nis, nis+ and possibly LDAP) What about when NIS or LDAP is in use ? Do we really want GDM attempting to display 38,000+ accounts ? As I explain above, this should not be an issue. So no getent? How does gdm detect which users logged in before? Casper
In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009]
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: In-kernel pfexec implementation. 1.2. Name of Document Author/Supplier: Author: Casper Dik 1.3 Date of This Document: 03 July, 2009 4. Technical Description I'm sponsoring this fasttrack for myself. This project proposes an in-kernel implementation of the pfexec(1) command. This case was approved during the psarc meeting on Wednesday 8th, 2009. Casper
Basic File Privileges [PSARC/2009/378 FastTrack timeout 7/10/2009]
This case was approved during the psarc meeting on Wednesday 8th, 2009. Casper
In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009]
Does this mean that the need for the existence of the /usr/bin/pfexec program will remain? OK, from readin below this seems to be true. Yes, that is correct. ... or will there be a file system attribute that allows to create spfexec executable file behavior? No. (Note that exec_attrs belong to a profile, not the executable) The pfexecd is started at boot through SMF as svc:/system/pfexecd. Implementing pfexec in the kernel delivers the following advantages: - pfshells come at no charge; this project will deliver the following pf*sh*: pfbash pfcsh pfksh pfksh93 pfsh pftcsh pfzsh A pf*sh* starts, sets the PRIV_PFEXEC flag and executes the shell. Code which supports profile shells in current shells will be removed. You mean the code that shifts the arg vector and that prepends /usr/bin/pfexec ? Correct. /usr/bin/pfcsh [ options ] [ argument ]... + /usr/bin/pftcsh [ options ] [ argument ]... + /usr/bin/pfksh [ options ] [ argument ]... + /usr/bin/pfksh93 [ options ] [ argument ]... + + /usr/bin/pfbash [ options ] [ argument ]... + + /usr/bin/pfzsh [ options ] [ argument ]... + Will there be the possibility to turn on/off this feature like while the shell is running like I did implement in bsh and sh in ftp://ftp.berlios.de/pub/schily/ set -P # Turn on profile mode set +P # Turn off profile mode set -o profile # Turn on profile mode set +o profile # Turn off profile mode No; that use is wrong. A profile can be defined such that you can only run a few executables. Being able to disable the profileness of a shell is a bug because of that feature. I tried ksh93 and ksh and neither appears to support those. Casper
In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009]
If you call this a bug, when will the documentation (best practice) bug from Indiana be fixed that is based on manually calling pfexec? I don't see a relation between the two. I'm not responsible for abuse of pfexec; we could remove pfexec with this case but I have decided not to do that. Casper
Basic File Privileges [PSARC/2009/378 FastTrack timeout 7/10/2009]
On Mon, Jul 06, 2009 at 10:17:39PM +0200, Casper.Dik at Sun.COM wrote: hey casper, fyi, this is not how zones works. zones starts with the empty set and then adds privs. please see the brand config.xml files for where this is defined. you'll need to upate these files with these new privileges. (and feel free to file an RFE against zones to start with the basic set and then add or remove privs as necessary.) I looked through the code and it appears that the code tries to always adds basic to the 'default' set. It appears, then, that adding stuff the basic will just work except when you configure a zone without specifying default for limitpriv. oops. your right. i was confusing this with the need to update these config files with new non-basic privs that are required for correct system operation. Still, I think we should need to add an option to add basic,!needed to the required set for a particular brand. Casper
In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009]
On Sun, Jul 05, 2009 at 05:02:04PM +0200, Casper.Dik at Sun.COM wrote: Not so much exec_attr as getusernam(3C). And why would that fail? As root it might fail. The reason is that the directory might not want to let host entities see user data, while allowing users to see it. Enabling that was the point of self-credentialled name service lookups. In an environment that demands that pfexecd should fork helper processes to do the name service lookups as the users that are exec()ing things. The current implementation uses the client's effective uid and group id. pfexec() always calls getusernam() with an effective uid of root. Both the current implementation and the proposed implementation will call nscd with the same effective uid and no change in behaviour will be seen. Casper
Basic File Privileges [PSARC/2009/378 FastTrack timeout 7/10/2009]
fyi, this is not how zones works. zones starts with the empty set and then adds privs. please see the brand config.xml files for where this is defined. you'll need to upate these files with these new privileges. (and feel free to file an RFE against zones to start with the basic set and then add or remove privs as necessary.) Ok, that's clearly broken. Doesn't it work correctly for native zones? Casper
Basic File Privileges [PSARC/2009/378 FastTrack timeout 7/10/2009]
hey casper, fyi, this is not how zones works. zones starts with the empty set and then adds privs. please see the brand config.xml files for where this is defined. you'll need to upate these files with these new privileges. (and feel free to file an RFE against zones to start with the basic set and then add or remove privs as necessary.) I looked through the code and it appears that the code tries to always adds basic to the 'default' set. It appears, then, that adding stuff the basic will just work except when you configure a zone without specifying default for limitpriv. Casper
Basic File Privileges [PSARC/2009/378 FastTrack timeout 7/10/2009]
On Mon, Jul 06, 2009 at 08:18:38PM +0200, Casper.Dik at Sun.COM wrote: fyi, this is not how zones works. zones starts with the empty set and then adds privs. please see the brand config.xml files for where this is defined. you'll need to upate these files with these new privileges. (and feel free to file an RFE against zones to start with the basic set and then add or remove privs as necessary.) Ok, that's clearly broken. Doesn't it work correctly for native zones? all brands work the same way wrt privs handling. it's all controlled by the config.xml file. Check for BASIC_TOKEN in http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libzonecfg/common/libzonecfg.c#4950 and further. So generally will work. Unfortunately, the syntax used to describe privilege sets: privilege set=required name=proc_exec / actually only accepts single privileges. For the basic set, we'd really want something like: privilege set=required name=basic,!file_link_any,!proc_session,!procinfo / The property of the basic set is that you cannot portably enumerate it. Casper
In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009]
On Fri, Jul 03, 2009 at 02:08:07PM +0100, Darren J Moffat wrote: The pfexecd is started at boot through SMF as svc:/system/pfexecd. I'm assuming here that pfexecd is running as root with all privileges ? Or is it able to run with a reduced set (for example pfexecd shouldn't I think need most of the current basic privs or file_write from the new set in PSARC/2009/378). Though it feels to me like it should be running with all privs because other wise a lower privileged process is acting as an authority to hand out privs it doesn't actually have. What's wrong with pfexecd dropping privs after registering its door with the kernel? Because lesser privilege processes could subvert it. Casper
In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009]
On Fri, Jul 03, 2009 at 04:08:23PM +0200, Casper.Dik at Sun.COM wrote: PSARC 2005/133 covers the introduction of per-user nscd. It is enabled by setting 'enable-per-user-lookup'. Are you expecting that exec_attr and such will fail when they are attempted by root? Not so much exec_attr as getusernam(3C). And why would that fail? Casper
In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009]
On Fri, Jul 03, 2009 at 05:43:38AM -0700, Casper Dik wrote: The pfexecd is started at boot through SMF as svc:/system/pfexecd. - I thought we weren't supposed to keep the 'd' for daemon in service names. Fair enough. - What happens of this service is not online, or even, gasp, disabled? Is there a fallback on exec()ing the old pfexec, or is that just a shim now? (my guess: no fallback) No fallback. There's no old pfexec. Do exec()s block forever until the service is restarted? Do they block interruptibly? (my guess: yes) If the service isn't registered, you disable all profile shells and pfexec. That, I believe, is a feature. Is there any way for users to get notification that this service is not online when they attempt to use it through pfexec? (my guess: no) See above. - What about exec()ing set-uid programs when the service is unavailable? The kernel will also upcall to this service for those, right? If so, does that mean that if the service is offline then the only way to fix it is to login (not su, since it is set-uid!) as a user with sufficient privilege and/or authorization? Or is there any fallback on the old set-uid behavior in this case? (I have no guess about this case :) The file is still set-uid root; if the kernel cannot figure out which privileges to use, it will fallback to the old set-uid root behaviour. - Does the kernel cache results from pfexecd? (I'd be surprised if it didn't!) No, it doesn't. You don't cache things which are cheap to recompute, especially if we're compare this to a full exec. It may save a little but as you point out here, having a cache is expensive so we avoid it. If so, is there a way to prime this cache as a way to protect against problems with the service? (e.g., pre-load or hardcode entries for su(1M)). Is this cache flushed on service restart? On refresh? - Does refreshing the service accomplish anything else besides flushing any kernel-land cache? (my guess: no) There's no cache. Casper
Basic File Privileges [PSARC/2009/378 FastTrack timeout 7/10/2009]
On Fri, Jul 03, 2009 at 05:45:14AM -0700, Casper Dik wrote: This project proposes two new basic privileges. FILE_READ Allows a process to read a file or directory whose permission or ACL allow the process read permission. FILE_WRITE Allows a process to write a file or directory whose permission or ACL allow the process write permission. Does not having basic file privileges affect a process' ability to receive, via IPC, open file descriptors with contrary access? No. It might be useful to have a way to grant a process read and/or write access to specific objects while still denying it the right to do so in general. The simplest way to do that that I can imagine is by adding an additional pair of basic file privileges that apply only to files in the current directory (not following symlinks) and, perhaps, below. See, e.g., PSARC 2008/109 Casper
In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009]
On Sun, Jul 05, 2009 at 06:37:18AM -0500, Nicolas Williams wrote: Are you saying that there's now a way to separately specify privileges to force on exec() beyond what the process has in its limit set, or that the kernel grants less than full privilege (currently euid == 0 + oE = oP = L) to processes exec()ing set-uid programs for which there exist exec_attr(4) entries? If the former then I'd expect there should be more details. If the latter, then, does that apply regardless of whether PRIV_PFEXEC is set? And if the latter, what happens when exec()ing set-uid programs without matching exec_attr(4) entries? Is there any way to apply a wildcard rule to grant not privileges to processes running set-uid programs not listed in exec_attr(4)? The current implementation leaves the semantics of a set-uid root executable without an exec_attr entry unchanged. Casper
Basic File Privileges [PSARC/2009/378 FastTrack timeout 7/10/2009]
I'm happy with this case as specified so +1. I'm going on the assumption that this works for all filesystems that privileges currently work for. Thanks, At this point the implementation is such that if DAC permission is granted, then we never call any of the secpolicy routines. Clearly, for these privileges to work the filesystems need to be changed; when this project is completed, we will have complete support for the filesystems in OS-Net plus whatever support we will implement in the VOP_* layer. Other filesystems such as VxFS, QFS, SamFS will need to be modified. Casper
In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009]
I'm assuming here that pfexecd is running as root with all privileges ? Or is it able to run with a reduced set (for example pfexecd shouldn't I think need most of the current basic privs or file_write from the new set in PSARC/2009/378). Though it feels to me like it should be running with all privs because other wise a lower privileged process is acting as an authority to hand out privs it doesn't actually have. Yes, correct. Sorry for not bringing this next one up in the prereview but it only just popped into my head. In the current system pfexec itself will do the nameservice lookup to find the exec_attr entry to use. If I understand the new system it will be pfexecd doing that, right ? So this changes things with respect to per user nscd (needed for doing self credential'd lookups) in that user_attr, prof_attr and exec_attr lookups for 'pfexec' won't use the per user nscd ? Or am I missing something. Right. So where's the per-user nscd case? In the pre-review we discussed wither or not a TX configuration would have one pfexecd per system (in the global zone) or one per zone. This would ensure that pfexecd follows what happens with nscd which can be one in the global zone or one per zone. I can't tell from the case material what the decision was on that. There's apparently one nscd per TX system and it makes sense there's only one pfexecd in that schema. Casper
In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009]
PSARC 2005/133 covers the introduction of per-user nscd. It is enabled by setting 'enable-per-user-lookup'. Are you expecting that exec_attr and such will fail when they are attempted by root? In the pre-review we discussed wither or not a TX configuration would have one pfexecd per system (in the global zone) or one per zone. This would ensure that pfexecd follows what happens with nscd which can be one in the global zone or one per zone. I can't tell from the case material what the decision was on that. There's apparently one nscd per TX system and it makes sense there's only one pfexecd in that schema. txzonemgr can be used to change that between one per system and one per zone and the method script for svc:/system/name-service-cache sets it up. We'll make sure that we'll test pfexecd with TX configured. Casper
Basic File Privileges [PSARC/2009/378 FastTrack timeout 7/10/2009]
On Fri, 2009-07-03 at 05:45 -0700, Casper Dik wrote:
This project proposes two new basic privileges.
FILE_READ
Allows a process to read a file or directory whose
permission or ACL allow the process read permission.
FILE_WRITE
Allows a process to write a file or directory whose
permission or ACL allow the process write permission.
I have no problem with these new privileges, but do have one question
regarding the semantics of adding them to the basic set. How will this
affect processes that may be specifying individual privileges in the
basic set by enumeration rather than specifying basic itself in the
various APIs? Will they cease to be able to read and write files? Do
such applications exist?
When define a set of privileges, you must start with the basic set.
This is how the basic set is defined. The basic set is extensible.
Perhaps we need to force that in SMF and in user_attr. Within Solaris, I
found only one manifest which listed needed privileges but it has recently
been fixed.
The private interfaces __init_daemon_priv and __init_suid_priv will
always add the basic set.
The only time when we actually set a limit set to {empty} is by setting
the limit set but we only do that when we do not expect any execve calls.
Casper
Basic File Privileges [PSARC/2009/378 FastTrack timeout 7/10/2009]
Right; SMF manifests is one area that I was thinking where this could have been a problem. Another is applications that might be doing this kind of thing: 1. application starts with all kinds of privileges including basic 2. application needs to fork a child that only needs to read and write to files it owns 3. application calls fork, and then in the child calls setppriv() with the empty set assuming that it needs no privileges to read and write files that it owns I think these (if they exist) will break. I know I have one of these in my project gate that I'll have to fix. ;-) Yeah, I guess you didn't follow the guidelines but if they are not spelled out then we need to fix the documentation. Perhaps it's hidden too well, but there are such bits as: To maintain future compatibility, the basic set of privileges is included as basic,!missing_basic_priv1, When further currently unprivileged operations migrate to the basic privilege set, the conversion back of the result with priv_str_to_set() includes the additional basic privileges, guaranteeing that the resulting privilege set carries the same privileges. This behavior is the default and is equivalent to specifying a flag argument of PRIV_STR_PORT. Casper
Update GNU coreutils to version 7.4 [PSARC/2009/355 FastTracktimeout 06/22/2009]
presumably solaris -u could fail in the creat/unlink steps that gnu bypasses the ksh mktemp builtin -u implementation follows the solaris docs Well, actually: if (dounlink) (void) unlink(tmpl); I would need to read the GNU code before I know what it does. Casper
Update GNU coreutils to version 7.4 [PSARC/2009/355 FastTrack timeout 06/22/2009]
/usr/bin already has an mktemp. How does it differ from the GNU version? Ah, there's an option conflict, sadly (-u is --dry-run in GNU, but unsafe operation in Solaris). Solaris' mktemp takes after the OpenBSD mktemp. Casper
disktype [PSARC/2009/356 FastTrack timeout 06/21/2009]
If it can't detect ZFS on a disk then I don't think it is useful for OpenSolaris given that the root filesystem disk will be a ZFS disk. Not showing that ZFS is on a disk on Solaris/OpenSolaris system is actually dangerous as it could lead the user to assume the disk was empty. But isn't it true that tools which modify disks will complain? Casper
Update GNU coreutils to version 7.4 [PSARC/2009/355 FastTrack timeout 06/22/2009]
On Tue, Jun 16, 2009 at 09:55:30AM +0200, Casper.Dik at Sun.COM wrote: /usr/bin already has an mktemp. How does it differ from the GNU version? Ah, there's an option conflict, sadly (-u is --dry-run in GNU, but unsafe operation in Solaris). Solaris' mktemp takes after the OpenBSD mktemp. What is the point of the Solaris mktemp(1) -u option though? Why would anyone choose unsafe operation? It came from OpenBSD. I can understand the reason, though, you can't always want to create a file, you may want an unique value: unique=$(mktemp -u XX) Casper
Update GNU coreutils to version 7.4 [PSARC/2009/355 FastTracktimeout 06/22/2009]
Ok... that makes sense... :-) Erm... what is the stabilty state of -u - wasn't it Commited Obsolete ? If that's the case it may be nice to get rid of the Obsolete and poke the GNU coreutils maintainers to rename the dryrun option to something else (I'll poke AST+BSD upstream to do the same for their mktemp command (e.g. clarify documentation)). I don't think so; it's in the manual page. I'm the only person clever enough to realize that mktemp -u in OpenBSD and Solaris is the exact same function as --dryrun in GNU coreutils? -u, --dry-run do not create anything; merely print a name (unsafe) Casper
Update GNU coreutils to version 7.4 [PSARC/2009/355 FastTracktimeout 06/22/2009]
On Tue, 16 Jun 2009 20:31:54 +0200 Casper.Dik at sun.com wrote: I don't think so; it's in the manual page. I'm the only person clever enough to realize that mktemp -u in OpenBSD and Solaris is the exact same function as --dryrun in GNU coreutils? -u, --dry-run do not create anything; merely print a name (unsafe) not the same as solars mktemp(1) subtle difference is if the creat/mkdir happens or not and if it does -u does an unlink/rmdir -u Operate in unsafe mode. The temp file is unlinked before mktemp exits. This is slightly better than mktemp(3C), but still introduces a race condition. Use of this option is discouraged. In GNU or ksh93? It's merely semantics, I think,; you can't make sure that a filename is unique other than creating it with O_EXCL so we need to unlink and we're certain that the file was unique at some point in time. I think they have the same root but someone didn't properly clone mktemp(). Casper
2009/327 [system_noshell]
R I think it would be helpful to see a few worked examples that show how system_noshell() and its variants make things simpler than using posix_spawn(). Date: Fri, 29 May 2009 10:41:30 -0700 From: Sumanth Naropanth Sumanth.Naropanth at sun.com Subject: Re: system_noshell [PSARC/2009/327 FastTrack timeout 06/05/2009] ... system_noshell(/bin/rm /tmp/tmpfile) is simpler than posix_spawn(pid, rm, NULL, NULL, argv, NULL) which also includes populating an argv vector. The example given above is a start, but I'd like to see something more realistic. If we're going to *parse* commands using spaces or what not, I vote no, right now! Casper
2009/327 [system_noshell]
Glenn Skinner wrote: I think it would be helpful to see a few worked examples that show how system_noshell() and its variants make things simpler than using posix_spawn(). Date: Fri, 29 May 2009 10:41:30 -0700 From: Sumanth Naropanth Sumanth.Naropanth at sun.com Subject: Re: system_noshell [PSARC/2009/327 FastTrack timeout 06/05/2009] ... system_noshell(/bin/rm /tmp/tmpfile) is simpler than posix_spawn(pid, rm, NULL, NULL, argv, NULL) which also includes populating an argv vector. The example given above is a start, but I'd like to see something more realistic. Yes. In the case above, unlink(/tmp/tmpfile) would be better than either, and a lot more efficient! :-) Quite; and what if the argument is /tmp/tmpfile /etc/shadow? if we do that, it's still an unsafe interface. Casper
system_noshell [PSARC/2009/327 FastTrack timeout 06/05/2009]
If not used carefully, the system(3C) function may be responsible for the following security concerns: + Execution of the command is affected by the PATH, IFS and other environment variables. None of our current shells evaluates the IFS environment variable. PROPOSED SOLUTION: The system_noshell(3C) function call will be implemented to provide the same ease of use as the system(3C) function, via a single (const char *) argument. Variants of this function will be system_noshell_x(3C) and system_noshell_xv(3C) which will allow for special arguments to be passed while executing a file. Prototypes: --- system_noshell(const char *abs_path); system_noshell_x(const char *abs_path, uint_t flags, const char *arg0, ... /* const char *argn, (char *)0 */); system_noshell_xv(const char *abs_path, uint_t flags, char *const argv[]); Are these wrappers for posix_spawn? And why can't we use posix_spawn as it is? posix_swap(pid, abs_path, NULL, NULL, argv, NULL) is nearly the same as system_noshell_vx. If people don't use posix_spawn, why do you suspect they will use system_no_shell*? Where is the environment set? Why are the _x and _xv suffices more like exec(): (execl, execv: l for list, v for a vector) Casper
system_noshell [PSARC/2009/327 FastTrack timeout 06/05/2009]
Casper.Dik at sun.com wrote: If not used carefully, the system(3C) function may be responsible for the following security concerns: + Execution of the command is affected by the PATH, IFS and other environment variables. None of our current shells evaluates the IFS environment variable. The Bourne Shell (bin/sh) does. Not in Solaris; it was fixed before Solaris 7 (bug 4077929) Casper
Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/27/2009]
I'm not at all a Linux expert and could be reading it wrong, but it appears to want the caller of the ioctl to have the CAP_SYS_ADMIN capability if they aren't writing to the current processes' terminal. FreeBSD it looks like the ioctl is #ifdef'd out OpenBSD case TIOCSTI: /* simulate terminal input */ 964 if (p-p_ucred-cr_uid (flag FREAD) == 0) 965 return (EPERM); 966 if (p-p_ucred-cr_uid !isctty(p, tp)) 967 return (EACCES); That's pretty much what we have. Casper
PSARC 2009/320 Ralink RT2561/RT2561S/RT2661 IEEE802.11b/g Wireless Network Driver
In fact, Ralink wifi hardware has mainly 6 series: RT2500PCI, RT2500USB, RT2501/2600PCI, RT2501/2601USB, RT2700/2800PCI, RT2700/2800USB. Different hardware needs to download different firmware. And different hardware has different operation. Linux and BSD also has different driver for different Ralink hardware. Solaris rwd driver is ported from BSD. I would assume it's pretty much like the many Intel wifi drivers we have. (iwh, iwk, iwi) Casper
Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/27/2009]
Ok, for TIOCSTI, there are effectively three choices here. 1. maintain the current behaviour, which appears to require PRIV_ALL 2. modify the behaviour to allow the device owner to use TIOCSTI, when the sessions match. 3. modify the behaviour to allow the device owner to use TIOCSTI regardless of session. Casper appears to believe that 1 is the only sane answer. Nico appears to believe that 2 is a reasonable answer. I suspect that 3 is off the table. The current implementation is: if the ioctl flag is FREAD (read-only), then require all else if (the session is the same as the current session) then ok else require all So I'd say that the current behaviour is choice #2. But I think that's not what you actually want. Casper
Configurable Boot Archive Updates [2009/312 05/26/2009]
If the user can see this service fail, log into the system console, remount root as read/write, update the archive, and reboot into a working system, why can't the system itself just do this simply mechanical chore on its own? +1. (I will also need to reproduce a similar problem with smf which also needs to be fixed by the system) Casper
Amendments to pconsole fast-track [PSARC/2009/275 FastTrack timeout 05/08/2009]
On Thu, May 07, 2009 at 05:30:50PM +0200, 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 of their shells and then they come along and use pconsole to attach to the tty that shell is running in, they can only hijack a tty that they already own. Since they already own it and they already have access to the shell with the escalated privilege, I don't really see that as an issue. Perhaps you could give me the clue that helps me understand why they are getting to do something that they couldn't already do. But firefox can do that also (and acroread, and flash, etc). That's what the problem is. Not the action done by the user but what other software can do when running as you. They can also just debug your shells. But you can't do that on the su shell. What should hapen is that this ioctl should require a basic privilege that firefox and friends run without. (Also, we need to use labeling more for sandboxing.) Again, I don't agree. If TIOCSTI doesn't require privileges, then ANY PROCESS can paste input to any privileged shell. (Specifically, if someone steals just your password but not the root password or other passwords, changing TIOCSTI in this way allows such a user to: - paste input to su windows - paste input to remote (ssh) etc. And as long we don't sandbox firefox by default, changing TIOCSTI is a very wrong idea. It was always limited to root. Casper
