Re: remove polkit from core?
Le mardi 13 novembre 2012 à 16:10 -0500, Matthew Miller a écrit : On Tue, Nov 13, 2012 at 03:47:25PM -0500, Bill Nottingham wrote: Given the move of most system configuration at a large scale to things such as puppet and chef, I suspect that this argument has already lost in the marketplace. Obviously, we should still support more locked down configurations for the sites that need it, but programmatic application of system configuration is likely to stay. At least in the puppet/chef/etc cases you can tell when the system has fallen out of the config, but other than a diff/hash you're not going to be able to programmatically determine what it being out of configuration means for the system operation itself. Doesn't this make things _worse_ for puppet and chef and friends? When using those systems, it's nice to do the programmatic config and that level, and have easily-tweaked key value (or single value per file!) configuration. No, you can just use a template and hide it behind the proper abstraction. it make things worse for stuff like augeas however. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wed, Nov 14, 2012 at 07:34:22PM +, Jóhann B. Guðmundsson wrote: On 11/14/2012 07:33 PM, Richard W.M. Jones wrote: On Wed, Nov 14, 2012 at 09:44:55AM -0500, Gregory Maxwell wrote: On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams cmad...@hiwaay.net wrote: Great - let's take something that people are using, remove that functionality, and not announce it! This is not cool; it represents one of my biggest frustrations with a bunch of the new and improved ways of doing things. You track down how to do something, it works for a few releases, and then it doesn't anymore with no notice. I don't mind this much in isolation— and to some extent its unavoidable if there is to be progress. I also have the experience and impression that Fedora often dismisses use cases in the 'long tail' as things that power users can get by twiddling some opaque config file or registry entry or hacking some bit of code— this happens more often the closer you get to the desktop, but believe its a culture which permeates the project more generally than that. In isolation this too would be occasionally frustrating but finite in baddness. The combination of the two— that anything non-stock is subject to constant and often undocumented breakage _and_ that many non nearly-universal use cases are too non-mainstream to consider supportable stock features really diminishes the value I receive from using a distribution at all. I was trying yesterday to formulate a question for the people running for FESCo along these lines; also what they thought about: https://news.ycombinator.com/item?id=4772133 However I wasn't able to formulate a snappy and non-carping question in time for the deadline. Still, I do believe it's something that FESCo (those elected and those standing for election) ought to address. Why are other OS and upstream decision/discussion int their regard fesco problem? Should not their focus be first and foremost on our own distribution and our own OS? No. I think it's important to behave well with the larger free software community, and that includes other Linux distros and *BSD. From a purely selfish point of view, it leads to larger numbers of users testing our software in more configurations [different platforms, with and without different combinations of software installed], which is more likely to reveal bugs. Anyway, I'd like to hear what FESCo members have to say about this, because it would strongly influence who I would vote for. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wed, Nov 14, 2012 at 08:34:00PM -0500, Simo Sorce wrote: Also, creating individual groups for all the various privileged operations we have simply doesn't scale. This is a better argument. So, PK's usecase is a valid and an important one. You cannot replace that by Unix groups. Which is why it would be nice for it to at least have the option for a small, simple key-pair authority configuration format. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedora elections questions [Re: remove polkit from core?]
On Thu, Nov 15, 2012 at 09:43:41AM +, Richard W.M. Jones wrote: Anyway, I'd like to hear what FESCo members have to say about this, because it would strongly influence who I would vote for. Yeah, I too came up with a couple of questions I'd like to add to https://fedoraproject.org/wiki/F19_elections_questionnaire, but the question collection period is over. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora elections questions [Re: remove polkit from core?]
On Thu, Nov 15, 2012 at 9:19 AM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 15, 2012 at 09:43:41AM +, Richard W.M. Jones wrote: Anyway, I'd like to hear what FESCo members have to say about this, because it would strongly influence who I would vote for. Yeah, I too came up with a couple of questions I'd like to add to https://fedoraproject.org/wiki/F19_elections_questionnaire, but the question collection period is over. There will be a townhall where you or a proxy can ask them as well. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 11:53:16PM -0600, Ian Pilcher wrote: Wait. So the .pkla file I wrote to allow my run virt-manager as my normal user is going to stop working, and I'm going to have to write the replacement in JavaScript? This particular case is the primary one I've seen for people actually writing their own policy. I think maybe we should make a Unix group for it and make that the default. (But I don't think that solves the problem.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams cmad...@hiwaay.net wrote: Great - let's take something that people are using, remove that functionality, and not announce it! This is not cool; it represents one of my biggest frustrations with a bunch of the new and improved ways of doing things. You track down how to do something, it works for a few releases, and then it doesn't anymore with no notice. I don't mind this much in isolation— and to some extent its unavoidable if there is to be progress. I also have the experience and impression that Fedora often dismisses use cases in the 'long tail' as things that power users can get by twiddling some opaque config file or registry entry or hacking some bit of code— this happens more often the closer you get to the desktop, but believe its a culture which permeates the project more generally than that. In isolation this too would be occasionally frustrating but finite in baddness. The combination of the two— that anything non-stock is subject to constant and often undocumented breakage _and_ that many non nearly-universal use cases are too non-mainstream to consider supportable stock features really diminishes the value I receive from using a distribution at all. More on the subject— in this brave new polkit JS world, when an administrator is considering upgrading their Fedora (or even some packages), what tools will they have to validate that their local JS actually works at all much less produces the desired behavior? I don't see any tools or documentation to facilitate that.It seems to me that adding a bunch of unsound programmatic configuration which can't reasonably be used by the end users due the overhead of keeping up regular fedora churn, especially absent good validation tools, is not a productive change relative to just baking in the additional logic and exposing it via basic configuration switches. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wednesday, November 14, 2012 08:07:25 AM tim.laurid...@gmail.com wrote: On Wed, Nov 14, 2012 at 6:53 AM, Ian Pilcher arequip...@gmail.com wrote: On 11/13/2012 09:50 PM, Matthias Clasen wrote: Yes, this was a misunderstanding. What is still supported is the .policy files containing the default policy. And that is very good, since such policy files are installed by pretty much every package that uses polkit, while .pkla files were only used by very few packages. Wait. So the .pkla file I wrote to allow my run virt-manager as my normal user is going to stop working, and I'm going to have to write the replacement in JavaScript? Let's just say I'm struggling to find the words ... In F18 yes. http://davidz25.blogspot.dk/2012/06/authorization-rules-in-polkit.html This blog misses the most important property about security settings...they have to be auditable through automation. If you have 10,000 systems and need to know your security posture, you have to be able to check them through automation. If the javascript had a file over in /etc that it read configuration things from, then we are OK. But if we have to go check the code itself, there is a problem. -Steve http://www.freedesktop.org/software/polkit/docs/master/polkit.8.html Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wed, Nov 14, 2012 at 1:24 PM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Nov 13, 2012 at 11:53:16PM -0600, Ian Pilcher wrote: Wait. So the .pkla file I wrote to allow my run virt-manager as my normal user is going to stop working, and I'm going to have to write the replacement in JavaScript? This particular case is the primary one I've seen for people actually writing their own policy. I think maybe we should make a Unix group for it and make that the default. (But I don't think that solves the problem.) If David is unwilling to just resurrect the old .pkla parser, one option for solving the problem might be writing a piece of code that would provide compatibility with the .pkla files. This could be (the only) JS config snippet parsing the files directly if the JS environment allowed file system access, or alternatively a generator run before starting polkit to generate a large JS config representing the contents of .pkla files. Anyone interested in implementing it? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wed, Nov 14, 2012 at 09:44:55AM -0500, Gregory Maxwell wrote: On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams cmad...@hiwaay.net wrote: Great - let's take something that people are using, remove that functionality, and not announce it! This is not cool; it represents one of my biggest frustrations with a bunch of the new and improved ways of doing things. You track down how to do something, it works for a few releases, and then it doesn't anymore with no notice. I don't mind this much in isolation— and to some extent its unavoidable if there is to be progress. I also have the experience and impression that Fedora often dismisses use cases in the 'long tail' as things that power users can get by twiddling some opaque config file or registry entry or hacking some bit of code— this happens more often the closer you get to the desktop, but believe its a culture which permeates the project more generally than that. In isolation this too would be occasionally frustrating but finite in baddness. The combination of the two— that anything non-stock is subject to constant and often undocumented breakage _and_ that many non nearly-universal use cases are too non-mainstream to consider supportable stock features really diminishes the value I receive from using a distribution at all. I was trying yesterday to formulate a question for the people running for FESCo along these lines; also what they thought about: https://news.ycombinator.com/item?id=4772133 However I wasn't able to formulate a snappy and non-carping question in time for the deadline. Still, I do believe it's something that FESCo (those elected and those standing for election) ought to address. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On 11/14/2012 07:33 PM, Richard W.M. Jones wrote: On Wed, Nov 14, 2012 at 09:44:55AM -0500, Gregory Maxwell wrote: On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams cmad...@hiwaay.net wrote: Great - let's take something that people are using, remove that functionality, and not announce it! This is not cool; it represents one of my biggest frustrations with a bunch of the new and improved ways of doing things. You track down how to do something, it works for a few releases, and then it doesn't anymore with no notice. I don't mind this much in isolation— and to some extent its unavoidable if there is to be progress. I also have the experience and impression that Fedora often dismisses use cases in the 'long tail' as things that power users can get by twiddling some opaque config file or registry entry or hacking some bit of code— this happens more often the closer you get to the desktop, but believe its a culture which permeates the project more generally than that. In isolation this too would be occasionally frustrating but finite in baddness. The combination of the two— that anything non-stock is subject to constant and often undocumented breakage _and_ that many non nearly-universal use cases are too non-mainstream to consider supportable stock features really diminishes the value I receive from using a distribution at all. I was trying yesterday to formulate a question for the people running for FESCo along these lines; also what they thought about: https://news.ycombinator.com/item?id=4772133 However I wasn't able to formulate a snappy and non-carping question in time for the deadline. Still, I do believe it's something that FESCo (those elected and those standing for election) ought to address. Why are other OS and upstream decision/discussion int their regard fesco problem? Should not their focus be first and foremost on our own distribution and our own OS? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
- Original Message - On Wed, Nov 14, 2012 at 1:24 PM, Matthew Miller If David is unwilling to just resurrect the old .pkla parser, one option for solving the problem might be writing a piece of code that would provide compatibility with the .pkla files. This could be (the only) JS config snippet parsing the files directly if the JS environment allowed file system access, or alternatively a generator run before starting polkit to generate a large JS config representing the contents of .pkla files. Anyone interested in implementing it? The .pkla syntax wasn't particularly appealing or expressive, and there was only a handful of packages using it. I don't really think it is particularly worth reviving. If a declarative syntax is needed, I suggest that the security team simply picks their favourite language, and then implements a single js rule that calls out to a commandline utility implementing that language. Checking compliance should be very simple then - just check that the single single rule is the one you put in place. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Sat, 10.11.12 09:26, Richard W.M. Jones (rjo...@redhat.com) wrote: On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: Matthew Miller wrote: Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! And Unix groups worked OK before that (and still do for the majority of purposes). OK, I'll bite. So: Did they really? If you want to allow a user to execute a specific privileged operation once (let's say format a USB stick), and you grant him group membership for that, then he can drop a SETGID binary for that group somewhere and will have the permission forever. Effectively, you can never take group membership away. Also, creating individual groups for all the various privileged operations we have simply doesn't scale. So, PK's usecase is a valid and an important one. You cannot replace that by Unix groups. Making PK uninstallable hence really is not about removing something that was generally not necessary. It is simply about removing something that is not necessary in the specific usecase of a server setup where no local unprivileged users exist that might need to execute privileged operations interactively. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Thu, 2012-11-15 at 02:10 +0100, Lennart Poettering wrote: On Sat, 10.11.12 09:26, Richard W.M. Jones (rjo...@redhat.com) wrote: On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: Matthew Miller wrote: Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! And Unix groups worked OK before that (and still do for the majority of purposes). OK, I'll bite. So: Did they really? If you want to allow a user to execute a specific privileged operation once (let's say format a USB stick), and you grant him group membership for that, then he can drop a SETGID binary for that group somewhere and will have the permission forever. Effectively, you can never take group membership away. Not saying that groups are always the best option, but I am always amused by this permanent group membership. Makes it sound like nobody invented mounting homes with the nosuid mount option and that admins haven't yet discovered find -perm if indeed there is a file system where users are allowed to drop sgid set binaries ... Also, creating individual groups for all the various privileged operations we have simply doesn't scale. This is a better argument. So, PK's usecase is a valid and an important one. You cannot replace that by Unix groups. You might say that it would be difficult or inconvenient, but it can be replaced if you really want to. Whether it would make sense to try is a different story ... Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On 11/12/2012 08:00 PM, Steve Grubb wrote: except that most admins will never be able to do this. The only people that get any flexibility are people who manage their own system. Everyone else likely has some compliance issues and they have to be verifiably in configuration. What will happen is the generic js file will be SHA256 hashed and we'll check the file's hash in SCAP and report the system as out of configuration. This isn't completely sufficient—you also have to make sure that there isn't another Javascript snippet which overrides the operation of the valid script. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Hi Steve, On 12.11.2012 21:00, Steve Grubb wrote: I think its a bad idea to have too much flexibility for access control systems. They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG or any other standard, you have to be able to demonstrate you are in the approved config. No one can write a test that can tell if the rules really are sound. So, what will happen is one set will be chosen for better or worse, it will be SHA256 hashed. And no one can change anything in it without being out of compliance. The benefit of the name=value setup is that we can pick out the things that matter and skip everything else which truly gives flexibility when needing to demonstrate compliance. My question is: Whether be acceptable the required compliance analysis to be performed on rules written in simplified rule language like Datalog instead of imperative scripted evaluation in some future version of polkit ... ? (It seems to me that e.g. Datalog is good enough both as flexibility and static analysis (symbolic evaluation), furthermore IMO declarative rules are less error prone for sysadmins than scripting) Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tuesday, November 13, 2012 12:50:11 PM Alek Paunov wrote: Hi Steve, On 12.11.2012 21:00, Steve Grubb wrote: I think its a bad idea to have too much flexibility for access control systems. They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG or any other standard, you have to be able to demonstrate you are in the approved config. No one can write a test that can tell if the rules really are sound. So, what will happen is one set will be chosen for better or worse, it will be SHA256 hashed. And no one can change anything in it without being out of compliance. The benefit of the name=value setup is that we can pick out the things that matter and skip everything else which truly gives flexibility when needing to demonstrate compliance. My question is: Whether be acceptable the required compliance analysis to be performed on rules written in simplified rule language like Datalog instead of imperative scripted evaluation in some future version of polkit ... ? The standard that everyone is embracing for compliance checking is called SCAP. Parts of it are also being looked at by the IETF for standardization, too. I did a presentation on SCAP for the aqueduct project here: https://fedorahosted.org/aqueduct/attachment/wiki/Call/intro-SCAP-tech- talk.pdf XCCDF represents the policy that you wish to enforce. It is abstract in that it does not know exactly what file to access or how to perform the check. That is the job of OVAL, which is concrete in that it has the exact tests and knows which file to look at. The OVAL language has a number of checking mechanisms: http://oval.mitre.org/language/version5.10.1/OVAL_Language_Specification_01-20-2012.pdf For anything with name=value, we normally use the textfilecontent54 which we can define a regex to pick out the items of interest. However, with a language, you have multiple ways of expressing the same idea. for example, if (foo() 500) and uid = foo(); if (uid 500) and start = 500; uid = foo(); if (uid start) do the same thing. Then throw in comments and indentation and it you have lots of possibilities. This is also not considering whether the code actually meets the intent or allows unintended functionality (exploits). The only thing I can think of, using what's currently available in SCAP is to use filehash58 and call it a day. This has the drawback of notifying the admin that the hash doesn't match instead of a useful, actionable, message. They will be left wondering why the hash doesn't match and what they can do to fix it. This is not going to help security. This should be a lesson to anyone wanting to adopt a languge for system configuration and policy decision. (It seems to me that e.g. Datalog is good enough both as flexibility and static analysis (symbolic evaluation), furthermore IMO declarative rules are less error prone for sysadmins than scripting) Do you have a reference for it? I would almost think that you would want to specify system access rights in a Formal Language which supports the notion of proofs if anything like this were done. In that event, standards work would have to be done in preparation for this. I sit on the OVAL editorial Board, so I could raise the issue to the Board. But javascript for access control policy is a train wreck for anyone needing to demonstrate compliance. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tuesday, November 13, 2012 09:37:07 AM Steve Grubb wrote: For anything with name=value, we normally use the textfilecontent54 which we can define a regex to pick out the items of interest. However, with a language, you have multiple ways of expressing the same idea. for example, if (foo() 500) and uid = foo(); if (uid 500) and start = 500; uid = foo(); if (uid start) do the same thing. Then throw in comments and indentation and it you have lots of possibilities. This is also not considering whether the code actually meets the intent or allows unintended functionality (exploits). The only thing I can think of, using what's currently available in SCAP is to use filehash58 and call it a day. This has the drawback of notifying the admin that the hash doesn't match instead of a useful, actionable, message. They will be left wondering why the hash doesn't match and what they can do to fix it. And then if the javascript was found to have a vulnerability in it and it got fixed or perhaps updated to allow smartcard functionality or something...now the hash doesn't match. The old vulnerable hash will be forever encoded into guidance with almost no way to get a standards body to change it. With name = value, the vulnerability would likely be in the compiled code and the compliance check would pass. In this case the settings are verifiably correct because the config file is not changed and part of the compliance check usually involves running the OVAL content the Red Hat security response team generates which checks the rpm version. -Steve This is not going to help security. This should be a lesson to anyone wanting to adopt a languge for system configuration and policy decision. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 10:26:28AM -0500, Steve Grubb wrote: With name = value, the vulnerability would likely be in the compiled code and the compliance check would pass. In this case the settings are verifiably correct because the config file is not changed and part of the compliance check usually involves running the OVAL content the Red Hat security response team generates which checks the rpm version. This discussion seems significantly beyond remove polkit from core. I had seen the announcement about Javascript in Polkit and kinda shrugged -- not my ideal as a sysadmin, but, I thought, whatever. The concerns you raise go beyond the preferences of sysadmins (who, I think as a rule prefer key-value config files to complex ones). Of course, Fedora isn't (at least, not right now) targetted at the high-security situations you describe, but our major downstream consumer sure is. What (if anything) should Fedora do here? What are our options? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 4:40 PM, Matthew Miller mat...@fedoraproject.org wrote: The concerns you raise go beyond the preferences of sysadmins (who, I think as a rule prefer key-value config files to complex ones). Of course, Fedora isn't (at least, not right now) targetted at the high-security situations you describe, but our major downstream consumer sure is. What (if anything) should Fedora do here? What are our options? So, talking about specific actions... I have recently had to search all existing polkit policies. This is no longer possible to automate because various packages ship the JavaScript policy, so I had to review those by hand. It seems that (perhaps with the exception of polkit itself) any use of JavaScript could be converted into the old format, which remains supported. So, as soon I find some free time (probably next week), I intend to ask FPC to prohibit using JavaScript if the functionality can be represented in the old .pkla, and to prepare patches to convert the 6 JS-using packages. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
- Original Message - So, talking about specific actions... I have recently had to search all existing polkit policies. This is no longer possible to automate because various packages ship the JavaScript policy, so I had to review those by hand. It seems that (perhaps with the exception of polkit itself) any use of JavaScript could be converted into the old format, which remains supported. So, as soon I find some free time (probably next week), I intend to ask FPC to prohibit using JavaScript if the functionality can be represented in the old .pkla, and to prepare patches to convert the 6 JS-using packages. Not sure where you got that information. pkla files are not supported anymore. So, converting JavaScript rules to pkla syntax won't do any good. What is worthwhile doing though, is to review all existing packages that ship such rules, and stop them from doing that, if possible. JavaScript rules are only meant for admin use, no OS-provided package should install them. We only look in /usr/share to allow for the possibility of site-local configuration that is distributed in packages. A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in http://www.freedesktop.org/software/polkit/docs/latest/polkit-apps.html Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 02:07:53PM -0500, Matthias Clasen wrote: A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in So, is it fair to say that this allows the choice of: * auditable but with root-only access * configurable policy that doesn't meet the requirements for some secure enterprise uses ? I'm not going to spend a lot of time to oppose that, but I will note that it's sad to lose the middle ground provided by key-value configuration, when that covers a lot of cases. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tuesday, November 13, 2012 02:07:53 PM Matthias Clasen wrote: - Original Message - So, talking about specific actions... I have recently had to search all existing polkit policies. This is no longer possible to automate because various packages ship the JavaScript policy, so I had to review those by hand. It seems that (perhaps with the exception of polkit itself) any use of JavaScript could be converted into the old format, which remains supported. So, as soon I find some free time (probably next week), I intend to ask FPC to prohibit using JavaScript if the functionality can be represented in the old .pkla, and to prepare patches to convert the 6 JS-using packages. Not sure where you got that information. pkla files are not supported anymore. So, converting JavaScript rules to pkla syntax won't do any good. What is worthwhile doing though, is to review all existing packages that ship such rules, and stop them from doing that, if possible. JavaScript rules are only meant for admin use, no OS-provided package should install them. We only look in /usr/share to allow for the possibility of site-local configuration that is distributed in packages. Turning system configuration into a scriptable language is like going back in time to the 70's and early 80's where you modified the source to have a different behavior. Remember Basic programs where if you wanted it to do something new, you change your copy so its better that the one people were sharing? It was decided a long time ago that its better to just have a parser that looks for the things that people would commonly like to change. This way, you have some assurance that the main binary has some integrity and you didn't make some kind of typo that opens access for the world. As a matter of fact, the better way to do this is via some kind of daemon that keeps all this information in one giant database. This way its possible to audit any change to the database and know who did it, what they changed, and what the old and new values are. This level of service was asked for by government agencies. We pointed to the sshd config file and said its impossible. I canplace a watch on the file and I can tell you who changed it and I can tell you when they changed it, but I cannot tell you what in it changed. This is the direction I'd rather see the OS go instead of going back to what amounts to changing the source code. We need to improve the verifiablity rather than the flexibility. A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in http://www.freedesktop.org/software/polkit/docs/latest/polkit-apps.html We have security configurations for desktop systems. This proposal fixes the minimal install issue but does not address the compliance issue. -Steve http://en.wikipedia.org/wiki/Configuration_file -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 02:32:28PM -0500, Steve Grubb wrote: It was decided a long time ago that its better to just have a parser that looks for the things that people would commonly like to change. This way, you have some assurance that the main binary has some integrity and you didn't make some kind of typo that opens access for the world. It occurs to me this is the exact _opposite_ of the change from init scripts to systemd service files. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 8:07 PM, Matthias Clasen mcla...@redhat.com wrote: - Original Message - So, talking about specific actions... I have recently had to search all existing polkit policies. This is no longer possible to automate because various packages ship the JavaScript policy, so I had to review those by hand. It seems that (perhaps with the exception of polkit itself) any use of JavaScript could be converted into the old format, which remains supported. So, as soon I find some free time (probably next week), I intend to ask FPC to prohibit using JavaScript if the functionality can be represented in the old .pkla, and to prepare patches to convert the 6 JS-using packages. Not sure where you got that information. pkla files are not supported anymore. My mistake - I meant the *.policy files in /usr/share/polkit-1/actions , which definitely do affect system behavior. What is worthwhile doing though, is to review all existing packages that ship such rules, and stop them from doing that, if possible. JavaScript rules are only meant for admin use, no OS-provided package should install them. Good, so we seem to agree on this part. That would resolve my concerns (ability to ability to analyze configuration shipped in Fedora by a program), but not Steve's (ability to analyze admin's customized configuration). A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in Hm, I don't like that much. Having two completely separate authorization code paths in many software components makes it very likely that the less frequently used code path will be buggy at least in some components. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Miloslav Trmač (m...@volny.cz) said: A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in Hm, I don't like that much. Having two completely separate authorization code paths in many software components makes it very likely that the less frequently used code path will be buggy at least in some components. Applications are already supposed to be able to cope with polkitd not being present; it's not really an authorization code path as much as it is just good defensive coding. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Steve Grubb (sgr...@redhat.com) said: So, converting JavaScript rules to pkla syntax won't do any good. What is worthwhile doing though, is to review all existing packages that ship such rules, and stop them from doing that, if possible. JavaScript rules are only meant for admin use, no OS-provided package should install them. We only look in /usr/share to allow for the possibility of site-local configuration that is distributed in packages. Turning system configuration into a scriptable language is like going back in time to the 70's and early 80's where you modified the source to have a different behavior. Remember Basic programs where if you wanted it to do something new, you change your copy so its better that the one people were sharing? It was decided a long time ago that its better to just have a parser that looks for the things that people would commonly like to change. This way, you have some assurance that the main binary has some integrity and you didn't make some kind of typo that opens access for the world. Given the move of most system configuration at a large scale to things such as puppet and chef, I suspect that this argument has already lost in the marketplace. Obviously, we should still support more locked down configurations for the sites that need it, but programmatic application of system configuration is likely to stay. At least in the puppet/chef/etc cases you can tell when the system has fallen out of the config, but other than a diff/hash you're not going to be able to programmatically determine what it being out of configuration means for the system operation itself. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 03:47:25PM -0500, Bill Nottingham wrote: Given the move of most system configuration at a large scale to things such as puppet and chef, I suspect that this argument has already lost in the marketplace. Obviously, we should still support more locked down configurations for the sites that need it, but programmatic application of system configuration is likely to stay. At least in the puppet/chef/etc cases you can tell when the system has fallen out of the config, but other than a diff/hash you're not going to be able to programmatically determine what it being out of configuration means for the system operation itself. Doesn't this make things _worse_ for puppet and chef and friends? When using those systems, it's nice to do the programmatic config and that level, and have easily-tweaked key value (or single value per file!) configuration. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Miloslav Trmač wrote: I have recently had to search all existing polkit policies. This is no longer possible to automate because various packages ship the JavaScript policy, so I had to review those by hand. It seems that (perhaps with the exception of polkit itself) any use of JavaScript could be converted into the old format, which remains supported. Actually, we were told multiple times that .pkla is no longer supported and no longer works and that we all have to use JavaScript .rules in F18+. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
- Original Message - Miloslav Trmač wrote: I have recently had to search all existing polkit policies. This is no longer possible to automate because various packages ship the JavaScript policy, so I had to review those by hand. It seems that (perhaps with the exception of polkit itself) any use of JavaScript could be converted into the old format, which remains supported. Actually, we were told multiple times that .pkla is no longer supported and no longer works and that we all have to use JavaScript .rules in F18+. Yes, this was a misunderstanding. What is still supported is the .policy files containing the default policy. And that is very good, since such policy files are installed by pretty much every package that uses polkit, while .pkla files were only used by very few packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On 11/13/2012 09:50 PM, Matthias Clasen wrote: Yes, this was a misunderstanding. What is still supported is the .policy files containing the default policy. And that is very good, since such policy files are installed by pretty much every package that uses polkit, while .pkla files were only used by very few packages. Wait. So the .pkla file I wrote to allow my run virt-manager as my normal user is going to stop working, and I'm going to have to write the replacement in JavaScript? Let's just say I'm struggling to find the words ... -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wed, Nov 14, 2012 at 6:53 AM, Ian Pilcher arequip...@gmail.com wrote: On 11/13/2012 09:50 PM, Matthias Clasen wrote: Yes, this was a misunderstanding. What is still supported is the .policy files containing the default policy. And that is very good, since such policy files are installed by pretty much every package that uses polkit, while .pkla files were only used by very few packages. Wait. So the .pkla file I wrote to allow my run virt-manager as my normal user is going to stop working, and I'm going to have to write the replacement in JavaScript? Let's just say I'm struggling to find the words ... In F18 yes. http://davidz25.blogspot.dk/2012/06/authorization-rules-in-polkit.html http://www.freedesktop.org/software/polkit/docs/master/polkit.8.html Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On 11/10/2012 05:26 PM, Ville Skyttä wrote: On 2012-11-09 18:27, Matthew Miller wrote: The js package is 6.5MB. BTW I suppose that could be significantly reduced by linking /usr/bin/js with the dynamic libmozjs instead of the static one generated during the build. It seems to take something more than just the attached patch though. Most interpreters deliberately do this because non-PIC code is significantly faster than PIC code, especially on architectures without IP-relative addressing. These days, it may be possible to recover some of the lost performance by tweaking ELF symbol visibility or amalgamation builds (that is, stuffing everything in a single C file; -flto could perhaps provide an equivalent). -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Saturday, November 10, 2012 09:26:26 AM Richard W.M. Jones wrote: On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: Matthew Miller wrote: Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! And Unix groups worked OK before that (and still do for the majority of purposes). Another problem is how would we do SCAP configuration checks when the language will allow 20 different ways to do the same thing? We might be able to do a SHA256 has of the js. Which means you've completely lost any ability to modify the behaviour. In an ini file, we could pick out the lines that were important and check them only allowing other settings we don't care about to change. Additionally, access control decisions should be audited. There are no libaudit bindings for javascript. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Mon, Nov 12, 2012 at 10:37:54AM -0500, Steve Grubb wrote: Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! Another problem is how would we do SCAP configuration checks when the language will allow 20 different ways to do the same thing? We might be able to do a SHA256 has of the js. Which means you've completely lost any ability to modify the behaviour. In an ini file, we could pick out the lines that were important and check them only allowing other settings we don't care about to change. Additionally, access control decisions should be audited. There are no libaudit bindings for javascript. I'm very sympathetic to these concerns, but this is the way the upstream package has gone. How do we reconcile that? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Mon, Nov 12, 2012 at 09:41:22AM +0100, Florian Weimer wrote: On 11/10/2012 05:26 PM, Ville Skyttä wrote: On 2012-11-09 18:27, Matthew Miller wrote: The js package is 6.5MB. BTW I suppose that could be significantly reduced by linking /usr/bin/js with the dynamic libmozjs instead of the static one generated during the build. It seems to take something more than just the attached patch though. Most interpreters deliberately do this because non-PIC code is significantly faster than PIC code, especially on architectures without IP-relative addressing. Two notes: tis might be the default case upstream but it's not normal behaviour in what we package for Fedora: $ ldd `which perl`|grep libperl libperl.so = /usr/lib64/perl5/CORE/libperl.so (0x0034d1e0) $ ldd `which python`|grep libpython libpython2.7.so.1.0 = /lib64/libpython2.7.so.1.0 (0x0034da00) $ ldd `which ruby`|grep libruby libruby.so.1.9 = /lib64/libruby.so.1.9 (0x0034bca0) ajax (IIRC) analyzed the speed increase of non-PIC code when he worked on this: https://fedoraproject.org/wiki/User:Tibbs/Text_Relocation_Guidelines?rd=User:Tibbs/Static_Library_PICness_Guidelines#Rationale He found a small performance benefit, not significantly faster performance. He also made the case that non-PIC code has negative performance characteristics that are weighed against the gains. -Toshio pgpkVFxQ5J5RR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Sat, 2012-11-10 at 02:33 +0100, Kevin Kofler wrote: Matthew Miller wrote: Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! So that more complex rules-parsing can be done instead of hardcoded rules. For example, when creating a new WiFi network, NetworkManager could pass along the security options, network details, even the user that requested creating it. Administrator-written rules can factor all those details into the decision whether to allow/deny, which the existing static rules simply cannot do. Whether or not JS should be a *hard* dependency of PolicyKit, I don't know. But the feature is valuable, so don't dismiss it out-of-hand. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Monday, November 12, 2012 12:27:52 PM Dan Williams wrote: On Sat, 2012-11-10 at 02:33 +0100, Kevin Kofler wrote: Matthew Miller wrote: Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! So that more complex rules-parsing can be done instead of hardcoded rules. For example, when creating a new WiFi network, NetworkManager could pass along the security options, network details, even the user that requested creating it. Administrator-written rules can factor all those details into the decision whether to allow/deny, which the existing static rules simply cannot do. except that most admins will never be able to do this. The only people that get any flexibility are people who manage their own system. Everyone else likely has some compliance issues and they have to be verifiably in configuration. What will happen is the generic js file will be SHA256 hashed and we'll check the file's hash in SCAP and report the system as out of configuration. IOW, anyone running any sizeable operation just lost any flexibility. Whether or not JS should be a *hard* dependency of PolicyKit, I don't know. But the feature is valuable, so don't dismiss it out-of-hand. I think its a bad idea to have too much flexibility for access control systems. They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG or any other standard, you have to be able to demonstrate you are in the approved config. No one can write a test that can tell if the rules really are sound. So, what will happen is one set will be chosen for better or worse, it will be SHA256 hashed. And no one can change anything in it without being out of compliance. The benefit of the name=value setup is that we can pick out the things that matter and skip everything else which truly gives flexibility when needing to demonstrate compliance. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: Matthew Miller wrote: Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! And Unix groups worked OK before that (and still do for the majority of purposes). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On 2012-11-09 18:27, Matthew Miller wrote: The js package is 6.5MB. BTW I suppose that could be significantly reduced by linking /usr/bin/js with the dynamic libmozjs instead of the static one generated during the build. It seems to take something more than just the attached patch though. diff -up js-1.8.5/js/src/shell/Makefile.in~ js-1.8.5/js/src/shell/Makefile.in --- js-1.8.5/js/src/shell/Makefile.in~ 2011-03-31 22:08:36.0 +0300 +++ js-1.8.5/js/src/shell/Makefile.in 2012-11-10 18:22:13.647935875 +0200 @@ -52,7 +52,7 @@ CPPSRCS = \ DEFINES += -DEXPORT_JS_API -LIBS = $(NSPR_LIBS) $(EDITLINE_LIBS) $(DEPTH)/$(LIB_PREFIX)js_static.$(LIB_SUFFIX) +LIBS = $(NSPR_LIBS) $(EDITLINE_LIBS) -L$(DEPTH) -lmozjs185 LOCAL_INCLUDES += -I$(topsrcdir) -I.. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
remove polkit from core?
Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Fri, 09.11.12 11:27, Matthew Miller (mat...@fedoraproject.org) wrote: Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? We can work towards that but it requires a bit of changes in systemd. A number of systemd services check with PK for authorization if an unprivileged user tries to execute a privileged operation. Since we never really tested this on systems that lack PK the fallback code that bypasses PK if it is not around didn't really get the testing it deserved. Just today I made a minor fix to systemd git to deal nicely with PK-less systems. So, I think it makes sense to make PK truly optional, but this needs a bit of love in some layers of our stack, not just systemd but others as well, I presume. If somebody wants to work on it, please do, and file bugs whenever you notice that you get a PK related error message where a fallback to classic Unix UID-based security doesn't work as it should. David actually documented explicitly that daemons should fall back to classic Unix-style uid-based authoization if PK is found not to be around. It's clearly systemd's fault that we so far didn't follow this fully. Of course, it should be clear that making PK optional if a desktop is installed is not desirable, but other than that I think for head-less systems such as servers or embedded making PK optional would be desirable goal and worthwile to spend a bit of work on. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote: Of course, it should be clear that making PK optional if a desktop is installed is not desirable, but other than that I think for head-less systems such as servers or embedded making PK optional would be desirable goal and worthwile to spend a bit of work on. Cool, thanks for the input. There's little risk of it becoming optional on the desktop, because a large number of desktop packages sensibly have it as a requirement -- including gnome-shell and kde-runtime. (Xfce doesn't seem to have anything that directly requires it except for xfce4-power-manager, but other collatoral deps lead back to xfce-session.) I'm going to build some images without it and can start filing bugs on anything that comes up. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote: deserved. Just today I made a minor fix to systemd git to deal nicely with PK-less systems. Right now, I get: $ reboot Failed to issue method call: The name org.freedesktop.PolicyKit1 was not provided by any .service files Must be root. Which is fine except that I don't want to see the message. :) Does your fix handle this or should I bug report? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
1;3401;0cOn Fri, 09.11.12 12:22, Matthew Miller (mat...@fedoraproject.org) wrote: On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote: deserved. Just today I made a minor fix to systemd git to deal nicely with PK-less systems. Right now, I get: $ reboot Failed to issue method call: The name org.freedesktop.PolicyKit1 was not provided by any .service files Must be root. Which is fine except that I don't want to see the message. :) Does your fix handle this or should I bug report? Yes, that's the one that should be fixed with this: http://cgit.freedesktop.org/systemd/systemd/patch/?id=bece1f5215b4ff147e000255d07f6b3cc777f15b Would probably make sense to test things with this applied as it should solve most (but probably not all) issues related to PK-less systems. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Sat, 10.11.12 00:12, Paolo Bonzini (pbonz...@redhat.com) wrote: Il 09/11/2012 18:26, Lennart Poettering ha scritto: 1;3401;0cOn Fri, 09.11.12 12:22, Matthew Miller (mat...@fedoraproject.org) wrote: On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote: deserved. Just today I made a minor fix to systemd git to deal nicely with PK-less systems. Right now, I get: $ reboot Failed to issue method call: The name org.freedesktop.PolicyKit1 was not provided by any .service files Must be root. Which is fine except that I don't want to see the message. :) Does your fix handle this or should I bug report? Yes, that's the one that should be fixed with this: http://cgit.freedesktop.org/systemd/systemd/patch/?id=bece1f5215b4ff147e000255d07f6b3cc777f15b Would probably make sense to test things with this applied as it should solve most (but probably not all) issues related to PK-less systems. Isn't that the other way round? It fixes problems with uid=0, but Matthew is testing with uid!=0. Ah, right. Yeah. In that case the code already does the right thing, except that the error message is a bit misleading. It kinda suggests that PK was needed, but actually it just means I denied because you weren't root, and you can't get permission without PK either. I'll make sure the error message is corrected to just become a normal authentication denied message Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Matthew Miller wrote: Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! Since policykit was designed from the begining to support multiple authorities, it does seems like it might have been nicer to continue to support the ini-style local authority and add the js one as an extra option. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
