Re: RFE: Never, ever steal focus.
Quoting Adam Jackson (a...@redhat.com): On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote: On 1/6/10 11:07 AM, Adam Jackson wrote: PGA. Here's the challenge. To reply to this mail, I hit control-shift-r in one evo window, and evo opened a new window for me to compose into. Get it? I typed into one window, and then started typing into another, and that's exactly what was desired. If the window manager suppressed focus changes on the basis of you were just typing into some other window, this must be a focus steal, then the new compose window would have mapped unfocused, and I'd have to have alt-tabbed to get to it. So if you can come up with an algorithm that can reliably classify focus change requests as stealing or not, then great. I'd go with don't let a different app steal focus. Windows for the same currently focused app are allowed to. This works pretty well under Mac OS X. Might depend on some of the stuff being done by the gnome-shell folks though, to be able to group windows together as belonging to the same process/application to be able to do it Right under a Linux DE... Now make that work for the (not uncommon) case of clicking a link in evo or control-clicking one in gnome-terminal and expecting firefox to pop forward with that page. And now make that work for the case where firefox decides to take 10 secs to start up, so you start in another window, then firefox jumps up and grabs focus. Thanks. There is no case where I want a new window or popup to take focus. Makes for an easy algorithm. (hitting r in mutt is not a problem :) -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
Quoting Adam Jackson (a...@redhat.com): On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote: Quoting Adam Jackson (a...@redhat.com): On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote: I'd go with don't let a different app steal focus. Windows for the same currently focused app are allowed to. This works pretty well under Mac OS X. Might depend on some of the stuff being done by the gnome-shell folks though, to be able to group windows together as belonging to the same process/application to be able to do it Right under a Linux DE... Now make that work for the (not uncommon) case of clicking a link in evo or control-clicking one in gnome-terminal and expecting firefox to pop forward with that page. And now make that work for the case where firefox decides to take 10 secs to start up, so you start in another window, then firefox jumps up and grabs focus. Thanks. There is no case where I want a new window or popup to take focus. Makes for an easy algorithm. (hitting r in mutt is not a problem :) There is no case where _you_ want this, sure. Yes, exactly. You're saying that 1. there are cases where you want a window to pop up 2. it's too complicated to figure out which windows should pop up 3. so windows should always pop up, no point being configurable and ridiculing us over (2). I'm saying there are no cases where I want a popup, so we can easily have 2 configurable options: always have windows pop up and take focus, never have them do so. That's all. -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
Quoting Simo Sorce (sso...@redhat.com): On Wed, 6 Jan 2010 12:35:03 -0600 Serge E. Hallyn se...@us.ibm.com wrote: Yes, exactly. You're saying that 1. there are cases where you want a window to pop up 2. it's too complicated to figure out which windows should pop up 3. so windows should always pop up, no point being configurable and ridiculing us over (2). I'm saying there are no cases where I want a popup, so we can easily have 2 configurable options: always have windows pop up and take focus, never have them do so. That's all. You are actually asking for configuration options ? Haha, no :) I was just answering his question (come up with a way to identify windows to not pop up). When I get annoyed enough by it I'll either hack it in myself, or finally hack zoom into evilwm to use with xcompmgr and really be happy. That's not possible in the new order, where people is actively trimming out any word^woption that is redundant and deviates from the norm (the norm being what someone else like not necessarily what works best). /me bis bis bitter ;-) Shut up and rm that libfoo.a :) -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
Quoting Adam Jackson (a...@redhat.com): On Wed, 2010-01-06 at 12:35 -0600, Serge E. Hallyn wrote: Quoting Adam Jackson (a...@redhat.com): On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote: There is no case where I want a new window or popup to take focus. Makes for an easy algorithm. (hitting r in mutt is not a problem :) There is no case where _you_ want this, sure. Yes, exactly. You're saying that 1. there are cases where you want a window to pop up 2. it's too complicated to figure out which windows should pop up 3. so windows should always pop up, no point being configurable and ridiculing us over (2). I'm saying there are no cases where I want a popup, so we can easily have 2 configurable options: always have windows pop up and take focus, never have them do so. Ahh, I see the misunderstanding here: I'm not arguing point three. I'm not even really arguing point 2, as you phrased it; it's not _too_ complicated, it's merely complicated. I'm arguing that there exists an implementation that tries to prevent focus stealing, and trying to illustrate why that's a hard problem. And thus, why the OP's RFE as stated, is either not achievable, or not desirable. I mean, in some sense, this is all academic anyway. It's trivial to write an X app that steals focus, regardless of what the window manager Haha - yes, that's why it's tough to care much, there are certain apps I'm forced to run that will always steal focus :) sigh. attempts to implement. But even assuming you're running relatively well-behaved applications, it's still not an easy problem. -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Quoting Steve Grubb (sgr...@redhat.com): On Sunday 26 July 2009 07:32:36 pm Steve Grubb wrote: What can be done is that we program the application to drop some of the capabilities so that its not all powerful. There's just one flaw in this plan. The directory for /bin is 0755 root root. So, even if we drop all capabilities, the root acct can still trojan a system. If we change the bin directory to 005, then root cannot write to that directory unless it has the CAP_DAC_OVERRIDE capability. The idea with this project is to not allow network facing or daemons have CAP_DAC_OVERRIDE, but to only allow it from logins or su/sudo. As discussed at the Fesco meeting last week, the lower process capabilities project is going to reduce the scope of this part of the proposal. At this point, we are going to tighten up perms on the directories in $PATH, /lib[64], /boot, and /root. A sample srpm can be found here for anyone wanting to try it out before alpha is unfrozen. http://people.redhat.com/sgrubb/files/filesystem-2.4.24-1.fc12.src.rpm Any feedback would be appreciated. Hi Steve, downloading and looking at filesystem.spec in the above rpm, I don't see any special treatment for boot, root, or /lib Is the right rpm at that link? If so, then I must be misunderstanding - can you give me a diff or something to explain how it's supposed to work? thanks, -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: non root X
Quoting Dave Airlie (airl...@redhat.com): On Thu, 2009-08-06 at 01:36 -0400, Ben Boeckel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Airlie wrote: On Mon, 2009-08-03 at 15:08 +0530, Rahul Sundaram wrote: Hi A few days back I ran into http://lists.x.org/archives/xorg-devel/2009-July/001293.html I am wondering, since we are already using KMS in most places in Fedora, how far are we from achieving this by default in a Fedora release? non-root X is a big security hole at the moment, and until we get revoke() support in the kernel, we can probably move X to running as a special user, and maybe once we get revoke to running as the real user. However it doesn't solve the issue how we know we need or don't need root since X only figures out what graphics drivers are needed after starting, so if you needed a non-kms gpu driver we wouldn't know until after we'd started as non-root. Dave. Could permissions be raised temporarily? PolicyKit with (defaulted) auto-approve to load an appropriate driver? Maybe we could do something with SELinux, but I don't think we can do anything without getting revoke. or maybe some process capabilties if such things worked. The non-kms drivers could carry fe=on,fI=CAP_SYS_RAWIO (or whatever they need) and userids or groups allowed to run X could get pI=CAP_SYS_RAWIO at login through pam_cap.so. If you also make the x driver setuid-root, then on filesystems (like NFS) or kernels which don't support file capabilities, it'll run setuid root as it does now, while if file caps are supported then it should run as the calling user with just the granted capabilities. -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: non root X
Quoting Adam Jackson (a...@redhat.com): On Thu, 2009-08-06 at 14:50 -0500, Serge E. Hallyn wrote: Quoting Dave Airlie (airl...@redhat.com): Maybe we could do something with SELinux, but I don't think we can do anything without getting revoke. or maybe some process capabilties if such things worked. The non-kms drivers could carry fe=on,fI=CAP_SYS_RAWIO (or whatever they need) and userids or groups allowed to run X could get pI=CAP_SYS_RAWIO at login through pam_cap.so. If you also make the x driver setuid-root, then on filesystems (like NFS) or kernels which don't support file capabilities, it'll run setuid root as it does now, while if file caps are supported then it should run as the calling user with just the granted capabilities. It doesn't work like that. Drivers are DSOs, not executables. You drat -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Quoting Stephen Smalley (s...@tycho.nsa.gov): On Tue, 2009-07-28 at 17:53 -0400, Bill McGonigle wrote: On 07/28/2009 04:11 PM, Chris Adams wrote: AFAIK SELinux introduces additional controls and does not replace or override existing controls. I'm pretty sure non-root still can't directly listen on a low-numbered port. For some reason I thought it was possible with MAC, but I can't find anything to support that. I might have been thinking of Solaris privileges. There was a patch floated on selinux list circa June 2007 that would have allowed SELinux to directly grant capabilities. But it met a certain amount of resistance from people concerned about the implications of changing the historical position that SELinux only further restricts access and about how to handle states like permissive mode, selinux-disabled, etc seamlessly. http://marc.info/?l=selinuxm=118159187318524w=2 http://marc.info/?l=selinuxm=118192327422630w=2 http://marc.info/?l=selinuxm=118191791828777w=2 I suppose the main problem with relying on this for granting privilege to system processes would be that if the selinux policy wasn't loaded for some reason, such processes (sshd, login, ...) would fail. The same thing can happen at the moment with capabilities for an NFS rootfs, so perhaps the same solution (falling back to classic setuid if there is no selinux policy loaded) could apply? -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Quoting Bill McGonigle (b...@bfccomputing.com): On 07/28/2009 04:11 PM, Chris Adams wrote: Still, is such a change less severe than changing what root means? Is Fedora that committed to SELinux? What's it going to take to make most people who shut off SELinux stop doing that? Moving to heavier exploitation of capabilities doesn't mean stop using SELinux. Any more than finding and fixing buffer overflows should only be done if we want to turn off selinux. -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Quoting Steve Grubb (sgr...@redhat.com): On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote: I trust you meant to write 0555? No, I really mean 005 so that root daemons are using public permissions. Admins of course have DAC_OVERRIDE and can do anything. Try the script in a VM and tell me if there are any problems you see. I should elaborate more. The issue is that sometimes there are secrets that root admins have access to that should not be available to semi-trusted daemons. For example, any private keys in /root or /etc. You do not want any daemon that could be compromised to have access to these. So, its safest just to set the permissions to 0005 so that they have no access to /root. But 0555 will also prevent root without CAP_DAC_OVERRIDE from writing, no? Using 0005 will mean root also needs CAP_DAC_OVERRIDE to read/execute, which seems a bit much. Suddenly it needs extra privilege if i just want it to be able to execute /bin/date. That actually seems less secure in any real system. I expect a few corner cases, but other than /etc/resolve.conf I don't know of any problems. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
