On Sunday, June 09, 2013 05:04:50 PM Lennart Poettering wrote:
> You should not second guess the kernel, ...
True ...
> Then, doing these things in userspace makes these checks non-atomic. ...
True ...
> So, yeah, just trying to open the shm files *is the right thing to
> do*. And if audit d
On Mon, 10.06.13 16:01, Simo Sorce (s...@redhat.com) wrote:
> On Sun, 2013-06-09 at 17:17 +0200, Lennart Poettering wrote:
> > On Fri, 07.06.13 22:33, Richard W.M. Jones (rjo...@redhat.com) wrote:
> >
> > > On Fri, Jun 07, 2013 at 06:55:46PM +0200, Lennart Poettering wrote:
> > > > User "simo" cr
On Sun, 2013-06-09 at 17:17 +0200, Lennart Poettering wrote:
> On Fri, 07.06.13 22:33, Richard W.M. Jones (rjo...@redhat.com) wrote:
>
> > On Fri, Jun 07, 2013 at 06:55:46PM +0200, Lennart Poettering wrote:
> > > User "simo" creates /dev/shm/1000/ even though 1000 is the UID of user
> > > "lennart
On 06/10/2013 04:43 AM, Lennart Poettering wrote:
> On Sun, 09.06.13 11:05, Doug Ledford (dledf...@redhat.com) wrote:
>
>> The audit system is just a more modern version of that same thing. And
>> the second you put any sort of exception into the audit rules, then you
>> have to verify that the e
On Sun, 09.06.13 12:38, Colin Walters (walt...@verbum.org) wrote:
> On Sun, 2013-06-09 at 10:03 -0400, Steve Grubb wrote:
>
> > Why would anyone write software that is incorrect enough the OS spits it
> > back
> > as EINVAL?
>
> One example is the btrfs ioctl() for reflink:
>
> https://bugzi
On Sun, 09.06.13 11:05, Doug Ledford (dledf...@redhat.com) wrote:
> The audit system is just a more modern version of that same thing. And
> the second you put any sort of exception into the audit rules, then you
> have to verify that the exception can never be used to circumvent the
> legitimate
On Sun, Jun 09, 2013 at 04:55:40PM -0400, Doug Ledford wrote:
> I would never encourage it in terms of suggesting people try to second
> guess the kernel's rules and limitations. However, you can use such a
> technique to weed out otherwise known to fail cases, at least in
> instances like this w
On 06/09/2013 11:42 AM, Matthew Garrett wrote:
> On Sun, Jun 09, 2013 at 11:05:44AM -0400, Doug Ledford wrote:
>
>> And really, we've spent more time on this thread than it would take
>> Lennart to fix PA. Just a quick stat and check of uid before trying to
>> remove the stale files and this woul
On 06/09/2013 01:05 PM, Adam Williamson wrote:
> On Sun, 2013-06-09 at 16:44 +0200, Reindl Harald wrote:
>
>> where did you read this?
>
> Where Doug et al keep not responding to Lennart and Matthew's queries as
> to whether the correct fix is to the app or to the audit system, but
> keep repeati
On Sun, 2013-06-09 at 16:44 +0200, Reindl Harald wrote:
> where did you read this?
Where Doug et al keep not responding to Lennart and Matthew's queries as
to whether the correct fix is to the app or to the audit system, but
keep repeating that 'there's an audit error!'
> do yourself a favour an
On Sun, 2013-06-09 at 10:03 -0400, Steve Grubb wrote:
> Why would anyone write software that is incorrect enough the OS spits it back
> as EINVAL?
One example is the btrfs ioctl() for reflink:
https://bugzilla.gnome.org/show_bug.cgi?id=626497
--
devel mailing list
devel@lists.fedoraproject.
On Sun, Jun 09, 2013 at 11:05:44AM -0400, Doug Ledford wrote:
> And really, we've spent more time on this thread than it would take
> Lennart to fix PA. Just a quick stat and check of uid before trying to
> remove the stale files and this would all go away. Sure, your stat and
> remove could rac
On Sun, Jun 09, 2013 at 10:03:19AM -0400, Steve Grubb wrote:
> There isn't a mechanism to allow these to slip through. Over the years I have
> come to realize that the audit system can be a great resource for debugging
> user space. It was sitting through one of Dave Jones' why userspace sucks
On Sat, 08.06.13 11:35, Adam Williamson (awill...@redhat.com) wrote:
> On Sat, 2013-06-08 at 09:25 -0400, Steve Grubb wrote:
>
> > Its not quite like this. What I need is the OS to be well behaved under
> > normal
> > conditions so that when problems come along they are easily spotted. Fedora
On Fri, 07.06.13 22:33, Richard W.M. Jones (rjo...@redhat.com) wrote:
> On Fri, Jun 07, 2013 at 06:55:46PM +0200, Lennart Poettering wrote:
> > User "simo" creates /dev/shm/1000/ even though 1000 is the UID of user
> > "lennart". Lennart can never start PA again, ever. And can't do anything
> > ab
On Fri, 07.06.13 20:21, Miloslav Trmač (m...@volny.cz) wrote:
> AFAICS this can be solved by a ~100-line? patch to the pulseaudio
> ecosystem, or by doing much more work and coordicnation to design a
> different shm mechanism or a new shm namespace. I'm not planning to
> work on it so I suppose m
On Fri, 07.06.13 14:39, Bill Nottingham (nott...@redhat.com) wrote:
> Lennart Poettering (mzerq...@0pointer.de) said:
> > Yes, it is.
> >
> > POSIX shared memory doesn't define any useful scheme for automatic
> > removing of shared memory segments from /dev/shm after use. Hence, in
> > order to
On Fri, 07.06.13 15:35, Steve Grubb (sgr...@redhat.com) wrote:
> On Friday, June 07, 2013 07:29:56 PM Matthew Garrett wrote:
> > On Fri, Jun 07, 2013 at 02:02:14PM -0400, Simo Sorce wrote:
> > > The point is that we are simply throwing ideas off the wall as an aid in
> > > finding a way to solve t
On 06/09/2013 10:34 AM, Adam Williamson wrote:
> On Sun, 2013-06-09 at 10:03 -0400, Steve Grubb wrote:
>
>>> I don't think anyone wants these accesses to generate audit records. The
>>> question is whether the right way to fix that is to avoid those accesses
>>> in the first place or to provide a
On Fri, 07.06.13 14:02, Simo Sorce (s...@redhat.com) wrote:
> > Well, you know, this problem isn't new. Some SELinux AVCs can be set to
> > ignored for precisely reasons like this one, because it is common that
> > things like these happen: accesses which fail where that is
> > expected. You can c
On 06/09/2013 09:53 AM, Roberto Ragusa wrote:
> On 06/08/2013 04:13 PM, Doug Ledford wrote:
>>
>> Yes, but none of these results show the .12s time that your first
>> noatime test run showed in your original post. If you are now saying
>> that atime is faster than noatime by about .005 to .010s, t
On Sun, 2013-06-09 at 10:03 -0400, Steve Grubb wrote:
> > I don't think anyone wants these accesses to generate audit records. The
> > question is whether the right way to fix that is to avoid those accesses
> > in the first place or to provide a mechanism so that legitimate accesses
> > don't gen
On Sunday, June 09, 2013 05:56:42 AM Matthew Garrett wrote:
> On Sat, Jun 08, 2013 at 08:28:48PM -0400, Doug Ledford wrote:
> > On 06/08/2013 02:35 PM, Adam Williamson wrote:
> > > Well, you're defining something as 'bad behaviour' fairly arbitrarily -
> > > or at least controversially: not everyon
On 06/08/2013 04:13 PM, Doug Ledford wrote:
>
> Yes, but none of these results show the .12s time that your first
> noatime test run showed in your original post. If you are now saying
> that atime is faster than noatime by about .005 to .010s, then these
> results seem to show that. But your or
On Sat, Jun 08, 2013 at 08:28:48PM -0400, Doug Ledford wrote:
> On 06/08/2013 02:35 PM, Adam Williamson wrote:
> > Well, you're defining something as 'bad behaviour' fairly arbitrarily -
> > or at least controversially: not everyone agrees with your definition.
>
> Speaking as a former sysadmin re
On 06/08/2013 02:35 PM, Adam Williamson wrote:
> On Sat, 2013-06-08 at 09:25 -0400, Steve Grubb wrote:
>
>> Its not quite like this. What I need is the OS to be well behaved under
>> normal
>> conditions so that when problems come along they are easily spotted. Fedora
>> has been a fairly well
On 06/08/2013 10:29 AM, Steve Grubb wrote:
> On Saturday, June 08, 2013 10:13:45 AM Doug Ledford wrote:
>> Yes, but none of these results show the .12s time that your first
>> noatime test run showed in your original post. If you are now saying
>> that atime is faster than noatime by about .005 to
On Sat, 2013-06-08 at 09:25 -0400, Steve Grubb wrote:
> Its not quite like this. What I need is the OS to be well behaved under
> normal
> conditions so that when problems come along they are easily spotted. Fedora
> has been a fairly well behaved OS over the years. I have had to get a few
> a
On Sat, Jun 08, 2013 at 09:53:39AM -0400, Steve Grubb wrote:
> No real difference between them.
Make sure that you're testing this on a partition mounted with
strictatime.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.
On Saturday, June 08, 2013 10:13:45 AM Doug Ledford wrote:
> Yes, but none of these results show the .12s time that your first
> noatime test run showed in your original post. If you are now saying
> that atime is faster than noatime by about .005 to .010s, then these
> results seem to show that.
On 06/08/2013 10:10 AM, Steve Grubb wrote:
> On Saturday, June 08, 2013 09:57:03 AM Doug Ledford wrote:
>> Bad test. The first run took the hit for getting the file info into
>> page cache, after that, everything was run from cache and you got the
>> second result above and the results below. You
On Saturday, June 08, 2013 09:57:03 AM Doug Ledford wrote:
> Bad test. The first run took the hit for getting the file info into
> page cache, after that, everything was run from cache and you got the
> second result above and the results below. You have to make sure that
> from run to run the ca
On 06/08/2013 09:53 AM, Steve Grubb wrote:
> On Saturday, June 08, 2013 09:34:22 AM Steve Grubb wrote:
>> Does opening with noatime really make a measurable difference (assuming it
>> worked)? I suspect not since what we have now is 2 syscalls. It would
>> probably be faster to load icons without
On Saturday, June 08, 2013 09:34:22 AM Steve Grubb wrote:
> Does opening with noatime really make a measurable difference (assuming it
> worked)? I suspect not since what we have now is 2 syscalls. It would
> probably be faster to load icons without trying to set NOATIME.
Answering my own questi
On Sat, Jun 08, 2013 at 09:34:22AM -0400, Steve Grubb wrote:
> > Other than a heuristic based on whether a path is in the user's home
> > directory or not, the only way to avoid this is to stat before opening -
> > and that's obviously prone to failure.
> Does opening with noatime really make a mea
On Saturday, June 08, 2013 06:36:38 AM Matthew Garrett wrote:
> On Fri, Jun 07, 2013 at 05:24:30PM -0400, Steve Grubb wrote:
> > Hmm...sounds like kernel change. But in the meantime, most of the
> > offenders I see seem to have something to do with loading icons
>
> Sounds like code that doesn't di
On Saturday, June 08, 2013 06:33:11 AM Matthew Garrett wrote:
> On Fri, Jun 07, 2013 at 07:03:24PM -0600, Stephen John Smoogen wrote:
> > On 7 June 2013 12:29, Matthew Garrett wrote:
> > > So why not add a mechanism to permit applications to indicate that
> > > certain accesses they make should be
On Fri, Jun 07, 2013 at 05:24:30PM -0400, Steve Grubb wrote:
> Hmm...sounds like kernel change. But in the meantime, most of the offenders I
> see seem to have something to do with loading icons:
Sounds like code that doesn't differentiate between files that are in
user-local directories and sy
On Fri, Jun 07, 2013 at 07:03:24PM -0600, Stephen John Smoogen wrote:
> On 7 June 2013 12:29, Matthew Garrett wrote:
> > So why not add a mechanism to permit applications to indicate that
> > certain accesses they make should be ignored by audit?
> >
> Just so people know, this is like one of the
On Fri, Jun 07, 2013 at 06:55:46PM +0200, Lennart Poettering wrote:
> User "simo" creates /dev/shm/1000/ even though 1000 is the UID of user
> "lennart". Lennart can never start PA again, ever. And can't do anything
> about it, because "simo" is in control, and /dev/shm is sticky.
For /run we crea
On Friday, June 07, 2013 05:02:41 PM Colin Walters wrote:
> On Fri, 2013-06-07 at 22:14 +0200, Miloslav Trmač wrote:
> > On Fri, Jun 7, 2013 at 10:05 PM, Colin Walters wrote:
> > > On Fri, 2013-06-07 at 20:42 +0100, Matthew Garrett wrote:
> > >> Without further analysis, it doesn't tell us much. D
On Fri, Jun 07, 2013 at 04:06:30PM -0400, Steve Grubb wrote:
> Which is a bad patterm. O_NOATIME requires CAP_FOWNER
Documentation disagrees:
EPERM The O_NOATIME flag was specified, but the effective user ID of
the caller did not match the owner of the file and the caller
On Fri, 2013-06-07 at 22:14 +0200, Miloslav Trmač wrote:
> On Fri, Jun 7, 2013 at 10:05 PM, Colin Walters wrote:
> > On Fri, 2013-06-07 at 20:42 +0100, Matthew Garrett wrote:
> >
> >> Without further analysis, it doesn't tell us much. Does the code attempt
> >> to open a file O_NOATIME and then fa
On Fri, Jun 07, 2013 at 10:14:36PM +0200, Miloslav Trmač wrote:
> (IMHO only very special applications should use O_NOATIME; if it is
> not predictable which accesses do/don't update atime, the field
> completely loses its value.
It's already not especially predictable - we've been using relatime
On 6/7/13 3:06 PM, Steve Grubb wrote:
> On Friday, June 07, 2013 08:42:09 PM Matthew Garrett wrote:
>> On Fri, Jun 07, 2013 at 03:35:28PM -0400, Steve Grubb wrote:
>>> So far, the discussion has focused on pulseaudio. But what about the
>>> O_NOATIME issue?
>>
>> Without further analysis, it doesn'
On Fri, Jun 7, 2013 at 10:05 PM, Colin Walters wrote:
> On Fri, 2013-06-07 at 20:42 +0100, Matthew Garrett wrote:
>
>> Without further analysis, it doesn't tell us much. Does the code attempt
>> to open a file O_NOATIME and then fall back to trying it without?
>
> It's likely:
> https://bugzilla.g
On Friday, June 07, 2013 08:42:09 PM Matthew Garrett wrote:
> On Fri, Jun 07, 2013 at 03:35:28PM -0400, Steve Grubb wrote:
> > So far, the discussion has focused on pulseaudio. But what about the
> > O_NOATIME issue?
>
> Without further analysis, it doesn't tell us much. Does the code attempt
> to
On Fri, 2013-06-07 at 20:42 +0100, Matthew Garrett wrote:
> Without further analysis, it doesn't tell us much. Does the code attempt
> to open a file O_NOATIME and then fall back to trying it without?
It's likely:
https://bugzilla.gnome.org/show_bug.cgi?id=680326
Code:
https://git.gnome.org/brow
On Fri, Jun 07, 2013 at 03:35:28PM -0400, Steve Grubb wrote:
> So far, the discussion has focused on pulseaudio. But what about the
> O_NOATIME
> issue?
Without further analysis, it doesn't tell us much. Does the code attempt
to open a file O_NOATIME and then fall back to trying it without?
-
On Friday, June 07, 2013 07:29:56 PM Matthew Garrett wrote:
> On Fri, Jun 07, 2013 at 02:02:14PM -0400, Simo Sorce wrote:
> > The point is that we are simply throwing ideas off the wall as an aid in
> > finding a way to solve the issue for all.
>
> So why not add a mechanism to permit applications
Miloslav Trmač (m...@volny.cz) said:
> On Fri, Jun 7, 2013 at 8:39 PM, Bill Nottingham wrote:
> > Any reason we don't run with namespaced /dev/shm vis-a-vis private /tmp?
>
> Private /tmp is optional and not enabled for users sessions by
> default. For namespaced /dev/shm to impact pulseaudio,
On Fri, Jun 07, 2013 at 08:38:56PM +0200, Miloslav Trmač wrote:
> On Fri, Jun 7, 2013 at 8:29 PM, Matthew Garrett wrote:
> > So why not add a mechanism to permit applications to indicate that
> > certain accesses they make should be ignored by audit?
>
> Because it would be primarily useful to th
On Fri, Jun 7, 2013 at 8:39 PM, Bill Nottingham wrote:
> Any reason we don't run with namespaced /dev/shm vis-a-vis private /tmp?
Private /tmp is optional and not enabled for users sessions by
default. For namespaced /dev/shm to impact pulseaudio, it would have
to be applied automatically to eve
Lennart Poettering (mzerq...@0pointer.de) said:
> Yes, it is.
>
> POSIX shared memory doesn't define any useful scheme for automatic
> removing of shared memory segments from /dev/shm after use. Hence, in
> order to make sure that left-over segments don't fill up /dev/shm
> forever PA will try to
On Fri, Jun 7, 2013 at 8:29 PM, Matthew Garrett wrote:
> So why not add a mechanism to permit applications to indicate that
> certain accesses they make should be ignored by audit?
Because it would be primarily useful to the attackers' applications.
Or am I missing something? (BTW, audit already
On Fri, Jun 07, 2013 at 02:02:14PM -0400, Simo Sorce wrote:
> The point is that we are simply throwing ideas off the wall as an aid in
> finding a way to solve the issue for all.
So why not add a mechanism to permit applications to indicate that
certain accesses they make should be ignored by au
On Fri, Jun 7, 2013 at 6:55 PM, Lennart Poettering wrote:
>
> Well, you know, this problem isn't new. Some SELinux AVCs can be set to
> ignored for precisely reasons like this one, because it is common that
> things like these happen: accesses which fail where that is
> expected.
Well, whether i
On Fri, 2013-06-07 at 18:55 +0200, Lennart Poettering wrote:
> On Fri, 07.06.13 12:42, Simo Sorce (s...@redhat.com) wrote:
>
> > On Fri, 2013-06-07 at 18:21 +0200, Lennart Poettering wrote:
> > > On Fri, 07.06.13 12:09, Steve Grubb (sgr...@redhat.com) wrote:
> > >
> > > > > > > POSIX shared memor
On Friday, June 07, 2013 06:21:00 PM Lennart Poettering wrote:
> On Fri, 07.06.13 12:09, Steve Grubb (sgr...@redhat.com) wrote:
> > > > > POSIX shared memory doesn't define any useful scheme for automatic
> > > > > removing of shared memory segments from /dev/shm after use. Hence,
> > > > > in
> >
On Fri, 07.06.13 12:42, Simo Sorce (s...@redhat.com) wrote:
> On Fri, 2013-06-07 at 18:21 +0200, Lennart Poettering wrote:
> > On Fri, 07.06.13 12:09, Steve Grubb (sgr...@redhat.com) wrote:
> >
> > > > > > POSIX shared memory doesn't define any useful scheme for automatic
> > > > > > removing of
On Fri, 2013-06-07 at 18:21 +0200, Lennart Poettering wrote:
> On Fri, 07.06.13 12:09, Steve Grubb (sgr...@redhat.com) wrote:
>
> > > > > POSIX shared memory doesn't define any useful scheme for automatic
> > > > > removing of shared memory segments from /dev/shm after use. Hence, in
> > > > > ord
On Fri, 07.06.13 12:09, Steve Grubb (sgr...@redhat.com) wrote:
> > > > POSIX shared memory doesn't define any useful scheme for automatic
> > > > removing of shared memory segments from /dev/shm after use. Hence, in
> > > > order to make sure that left-over segments don't fill up /dev/shm
> > > >
On Friday, June 07, 2013 05:48:39 PM Lennart Poettering wrote:
> On Fri, 07.06.13 11:44, Steve Grubb (sgr...@redhat.com) wrote:
> > 88 times? Something changed. It didn't used to be this bad. Its doing this
> > over and over on the same file it was denied access on previously.
>
> Actually all lib
On Fri, 07.06.13 11:44, Steve Grubb (sgr...@redhat.com) wrote:
> 88 times? Something changed. It didn't used to be this bad. Its doing this
> over and over on the same file it was denied access on previously.
Actually all libpulse clients do this.
> > POSIX shared memory doesn't define any usef
On Fri, 2013-06-07 at 17:14 +0200, Lennart Poettering wrote:
> On Fri, 07.06.13 09:50, Steve Grubb (sgr...@redhat.com) wrote:
>
> > Let's look at one of these pule-shm events:
> > # ausearch --start today -k access -f pulse-shm -i --just-one
> >
> > type=PATH msg=audit(06/07/2013 07:13:46.377
On Friday, June 07, 2013 05:14:30 PM Lennart Poettering wrote:
> On Fri, 07.06.13 09:50, Steve Grubb (sgr...@redhat.com) wrote:
> > Let's look at one of these pule-shm events:
> > # ausearch --start today -k access -f pulse-shm -i --just-one
> >
> > type=PATH msg=audit(06/07/2013 07:13:46.377:
On Fri, 07.06.13 09:50, Steve Grubb (sgr...@redhat.com) wrote:
> Let's look at one of these pule-shm events:
> # ausearch --start today -k access -f pulse-shm -i --just-one
>
> type=PATH msg=audit(06/07/2013 07:13:46.377:215) : item=0 name=/dev/shm/pulse-
> shm-3756395503 inode=25089 dev=00:1
Hello,
Every now and then I look at the distribution to see that from an auditing
perspective the OS is nicely behaving in the absence of intrusion. Meaning we
are not getting audit events unnecessarily. One of the typical rules required
by the DISA STIG is to watch for file access being denied
68 matches
Mail list logo
