Hi Panu,
After a while break I am back with new problems J with regards to the
plugins. The use case now is like this:
Security plugin has a policy file (generalizing to any plugin, some
configuration file), which is complex enough that can be created/hardcoded
in plugin itself (even in
Should we do the stat passing then for fsmCommit hooks? I am attaching
the current state of my fsmCommit hooks just to show the place where I
was thinking to add them. I haven't checked the tabs and other stuff,
so this is just to give idea. I was thinking that instead of passing
mode_t to
, would make it easier indeed!
Best Regards,
Elena.
-Original Message-
From: Panu Matilainen [mailto:pmati...@laiskiainen.org]
Sent: Thursday, March 28, 2013 12:32 PM
To: Reshetova, Elena
Cc: rpm-maint@lists.rpm.org
Subject: Plugin findings
Hi,
There's really nothing like field-testing
After far too much pondering... I went ahead and added the prepare hook
+ some related bits and pieces. And actually ripped out SELinux support
from rpm core while at it, replaced by a simple SELinux plugin. Wohoo.
Looks cool :) Hope it works ;)
I think I'll leave the commit-hooks to you though
On 03/14/2013 03:01 PM, Reshetova, Elena wrote:
Sure, I'm not suggesting delaying everything until I someday get
around to fixing it, just that we could try thinking ahead for that
model to hopefully avoid having to change the plugin interfaces
later. I pushed a bunch of fsm changes
Sure, I'm not suggesting delaying everything until I someday get around to
fixing it, just that we could try thinking ahead for that model to hopefully
avoid having to change the plugin interfaces later. I pushed a bunch of fsm
changes yesterday, the two more interesting ones that we already
Do you want to do the changes? I can also try to do it tomorrow if
they aren't objections.
I probably should merge (at least some of) the study and link count patches
first, as those change the landscape quite a bit. I'll try to do that as soon
as the caffeine kicks in for good.
Sure, I
A file is a hard-link if (S_ISREG(st-st_mode) st-st_nlink 1) is true.
When erasing, we get this info from filesystem so that remains accurate (the
last one would be seen as the real file). On installation the stat struct
of a file is made up by rpm, so we can pass whatever we want in there.
On 03/06/2013 05:01 PM, Reshetova, Elena wrote:
What's missing is that another call to the hook is needed in
fsmMkdirs() for the unowned directories, and there we should perhaps pass
in the unowned
aspect somehow. Having a separate argument for that seems like an
overkill though... maybe we
Another issue I just realized is that with this patch, the metadata hook call
is not under the setmeta condition so it will get called always, ie in cases
like hardlinks when it specifically should *not* be called :)
I think the fsm-part should be something like this instead:
@@ -1569,6
I have been thinking about it now and I think having a hook for setting file
meta data is a good idea in any case (even if we decide to keep pre/post hooks
for some other purpose). It shows much clearer the purpose of the hook and it
can be placed nicely exactly where metadata is set (and
Looking at this, I just realized that rpm is currently doing chmod(),
chown() and all for each hardlink it creates, which just doesn't make
sense because ... by the very definition of a hardlink, it doesn't.
Probably worth fixing regardless of what we end up doing with hooks,
eg additional
Right, no surprises: there is an issue with hard links :)
Oh, this is smth I should have actually remembered, but forgot :( I saw the
issue a while back on our system setup, but since from security labelling
hard links aren't interesting (security context should be set on a file
itself, not a
I'm actually going to be mildly surprised if there aren't any strange cases
we've missed wrt hard links or such :) Anyway, the patch looks as
obviously-correct as it gets within fsm. Applied, thanks for the patch!
Yeah, but I guess we will hopefully find it out soon, when we will be using
the
Hi,
Hi, sorry about the delay... the recent patch-flood on rpm-maint caught me by
surprise :)
Patch flood is always good, total silence is much worse :)
I've cleaned it up somewhat now, for example the early return was just plain
wrong as it would've leaked resources all over the place. But
Hi,
I've started to wonder about the hook names though: open and close
seem out of place especially here (and to lesser degree elsewhere).
Perhaps these hooks should simply follow the pre/post pattern even in the
names, ie FILE_PRE and FILE_POST. I think it'd be more descriptive wrt what
they
Hi,
I am attaching the next version of the patch with modifications explained
inline below.
The patch looks deceptively simple :) In principle things look ok to me,
the issues I see have mostly to do with the symmetry part:
In fsmMkdirs(), the FileOpen() hook is not called, only
Hi,
Long time again since I replied :( Unfortunately had to resolve a number of
other issues and wanted to attach smth already to this mail as opposite to
just reply.
I have started from FSM hooks as you indicated and I am including the
initial version of patch for review based on our
Hi Panu,
I finally got back to file hooks and tried to look into this with a fresh
head. I think given our previous discussion, I would propose to have only
two symmetrical hooks inside FSM for plugins. I would also make rpm to
ignore any return code from them now, since there isn't much that
Hi
Agree, it looks nicer with 0/1 values: attaching the corrected one.
Best Regards,
Elena.
0001-Making-pre-post-tsm-psm-hooks-more-consistent.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
___
Rpm-maint
Hi,
I made a new small patch to clean up the existing pre/post hooks as we
discussed this week. After this is cleaned up, I can get back to fsm hooks.
After our recent discussion I think I need to reconsider places of some hooks,
for example post hook, or maybe make two post hooks?
One when
...@laiskiainen.org]
Sent: Thursday, November 29, 2012 2:38 PM
To: Reshetova, Elena
Cc: rpm-maint@lists.rpm.org
Subject: Re: Plugin ponderings
On 11/29/2012 01:52 PM, Reshetova, Elena wrote:
Yes, I am sorry: I have made two mistakes now:
1) patch is wrong (sent the intermediate version before
Much better late than never, the indentation is now exactly as it should
be, good! There's just one extra leftover indent level for the execv() call.
Oh, missed that one since it wasn't in diff: fixed now!
I'm afraid we'll need one more round: you perhaps took my that's what
RPMSCRIPTLET_EXEC bit
be a BIG change. Just maybe smth for really far future..
Just it could help improve robustness, too IMO.
Best Regards,
Elena.
-Original Message-
From: Panu Matilainen [mailto:pmati...@laiskiainen.org]
Sent: Tuesday, November 27, 2012 12:26 PM
To: Reshetova, Elena
Cc: rpm-maint
, 2012 1:38 PM
To: Reshetova, Elena
Cc: rpm-maint@lists.rpm.org
Subject: Re: Script hooks patch
On 11/26/2012 12:52 PM, Reshetova, Elena wrote:
Hi Panu,
I am working on the next version of script patch and will send it
hopefully today.
One thing that I noticed currently: I think header.c file
Hi,
I am attaching next version of the scriptlet-related patch. Next I will go
back to current hooks and make a small patch to make sure they are called as
we agreed.
Will do this tomorrow. Also some comments below:
There's eg RPMRC_NOTTRUSTED that could be (ab)used for certain types of
I see a couple of further problems with this:
- runLuaScript() will leak memory and a file descriptor if
rpmpluginsCallScriptPre() fails.
Sorry, will fix.
- For external scripts the hooks run on different sides of the fork():
pre-hook runs in the forked child, post-hook in the parent, so
Like said in some earlier email, there's not much hope getting the details
100% right the first time. The best way of finding out what works and what
doesn't is to try it out, so...
I started looking into creating a syslog plugin for rpm. One could argue
that logging is fundamental enough to be
Hi,
In the attachment promised patch for the script hooks: changing to have two
hooks instead of one and calling them for lua case, too.
Let me know what needs to be fixed J
Panu, I will reply to your other email tomorrow morning: I am falling asleep
already with this darkness around L
look at it
with fresh head.
The corrected patch attached!
Best Regards,
Elena.
From: Reshetova, Elena
Sent: Thursday, November 22, 2012 9:42 PM
To: rpm-maint@lists.rpm.org; Panu Matilainen
Subject: Script hooks patch
Hi,
In the attachment promised patch for the script hooks
The most important use-case is to make it possible to run scripts when even
/bin/sh is not available. Such as %pretrans scripts on initial install -
there simply nothing to exec() in that environment. Or if the package
containing /bin/sh or one of its dependencies needs scripts, there's no
other
Scripts run with all the powers that rpm itself has, and there's not a
whole lot that can be done about it: scriptlets expect to, and often need
to, do all sorts of crazy things.
True, but we would actually like to be able to limit things that scripts can
do. It is ok for a script to create a new
Oh and one other thing I noticed just now that'll need further thought:
currently the script setup hook only runs for external scripts, but
not the
embedded Lua-scripts. Which are getting more and more common...
They'll obviously need to be handled quite differently as they run
within
the
Okay then, done and pushed. Now that I looked closer, I spotted (and
fixed) a couple of more issues: a tiny memleak from early
rpmtsSetupTransactionPlugins() return and some further cosmetics (two
soft-tabs instead of one hard-tab, trailing whitespace etc), but nothing
dramatic.
Thank you! I
-
From: Panu Matilainen [mailto:pmati...@laiskiainen.org]
Sent: Thursday, November 01, 2012 10:22 AM
To: Reshetova, Elena
Cc: rpm-maint@lists.rpm.org
Subject: Re: [Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1
On 10/26/2012 12:56 PM, Reshetova, Elena wrote:
Hi,
Please find
@Tero, do you still remember the reason why the conflict hook was
done in this way? Why wasn't it better to check the conflicts before
the transaction and fail the whole transaction if conflicts are seen?
I'm not quite sure about the context you are talking about here, but
I'll tell what
Hi,
After reading your responses I think we indeed need to break this patch into
at least two or three parts. It would help us to concentrate on one set of
the hooks at the time and integrate them separately in steps.
You mentioned that pre/post tsm/psm hooks are pretty much fine, so we can
start
Hi,
Following up our recent discussion, I have composed a first patch in order
not to talk about the abstract concepts only.
I have taken the less intrusive approach and tried to integrate the new
hooks and the notion of security plugin
into the code with least amount of changes for core rpm and
Hi,
Adding back SELinux guys (wonder why they got stripped in the initial
posting: I blame the corporate mail client) :(
One question that we have is what is the best way to define a plugin
interface for rpm?
Should we define just security-related hooks and embed currently
existing
Hi,
I have been writing to the list a while back proposing a set of security
hooks that we need for rpm in Tizen.
I have discussed with SELinux guys (in CC) and we agreed that can should try
to define a unified interface that they can also use.
This would allow to move currently partly
/ereshetova/rpm/wiki/Security-Hooks-for-rpm
Best Regards,
Elena.
-Original Message-
From: rpm-maint-boun...@lists.rpm.org
[mailto:rpm-maint-boun...@lists.rpm.org] On Behalf Of Reshetova, Elena
Sent: Tuesday, November 01, 2011 12:52 PM
To: Panu Matilainen
Cc: rpm-maint@lists.rpm.org; Ware, Ryan
.
-Original Message-
From: rpm-maint-boun...@lists.rpm.org
[mailto:rpm-maint-boun...@lists.rpm.org] On Behalf Of Reshetova, Elena
Sent: Tuesday, November 01, 2011 12:52 PM
To: Panu Matilainen
Cc: rpm-maint@lists.rpm.org; Ware, Ryan R
Subject: Re: [Rpm-maint] Tizen rpm security plug-in interface
Hi
42 matches
Mail list logo
