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
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
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
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
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
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
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.
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
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
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
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
- 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
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
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
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
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
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
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()
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
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
- 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
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
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,
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
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
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
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
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
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
- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
48 matches
Mail list logo
