* Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework
From: Maxime Ripard @ 2015-02-26 13:21 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Stephen Boyd, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, Pawel Moll, Kumar Gala,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Mark Brown, Greg Kroah-Hartman
In-Reply-To: <54EEE46B.6090905-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Thu, Feb 26, 2015 at 09:16:27AM +0000, Srinivas Kandagatla wrote:
> I think we are making simple eeprom framework too smart which will
> break in future.
>
> IMHO, Anything on top of eeprom interface that interprets the data should
> not go into the eeprom framework itself, it can either live some parsers/SOC
> specific drivers/interfaces.
True, but that doesn't mean that this parser support can't be built
within the framework itself.
> As Stephen pointed out earlier lets start with something like this, which
> would provide a better abstraction to the discussed use cases like
> serial-number and packed data in eeprom.
>
> qfprom@1000000 {
> reg = <0x1000000 0x1000>;
> ranges = <0 0x1000000 0x1000>;
> compatible = "qcom,qfprom-msm8960"
>
> pvs-data: pvs-data@40 {
> compatible = "qcom,pvs-a";
> reg = <0x40 0x20>,
> };
>
> tsens-data: tmdata@10 {
> reg = <0x10 40>;
> };
>
> serial-number: serial@50 {
> compatible = "qcom,serial-msm8960";
> reg = <0x50 4>, <0x60 4>;
> };
>
> };
And I'm sorry, but I still don't get why the compatibles are needed
here.
> and then on the consumer side:
>
> device {
> eeproms = <&serial-number>;
> eeprom-names = "soc-rev-id";
> };
>
> driver side:
>
> eeprom_get_cell()
> eeprom_read();
Looks good otherwise.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: Documenting MS_LAZYTIME
From: Theodore Ts'o @ 2015-02-26 13:31 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Eric Sandeen, Ext4 Developers List, Linux btrfs Developers List,
XFS Developers, linux-man, Linux-Fsdevel, Linux API
In-Reply-To: <54EEDE23.6080009@gmail.com>
On Thu, Feb 26, 2015 at 09:49:39AM +0100, Michael Kerrisk (man-pages) wrote:
> > How about somethign like "This mount significantly reduces writes
> > needed to update the inode's timestamps, especially mtime and actime.
>
> What is "actime" in the preceding line? Should it be "ctime"?
Sorry, no, it should be "atime".
> I find the wording of there a little confusing. Is the following
> a correct rewrite:
>
> The advantage of MS_STRICTATIME | MS_LAZYTIME is that stat(2)
> will return the correctly updated atime, but the atime updates
> will be flushed to disk only when (1) the inode needs to be
> updated for filesystem / data consistency reasons or (2) the
> inode is pushed out of memory, or (3) the filesystem is
> unmounted.)
Yes, that's correct. The only other thing I might add is that in the
case of a crash, the atime (or mtime) fields on disk might be out of
date by at most 24 hours.
- Ted
^ permalink raw reply
* Re: Documenting MS_LAZYTIME
From: Michael Kerrisk (man-pages) @ 2015-02-26 13:36 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Eric Sandeen, linux-man, Linux API, XFS Developers, mtk.manpages,
Linux-Fsdevel, Ext4 Developers List, Linux btrfs Developers List
In-Reply-To: <20150226133113.GD11217@thunk.org>
On 02/26/2015 02:31 PM, Theodore Ts'o wrote:
> On Thu, Feb 26, 2015 at 09:49:39AM +0100, Michael Kerrisk (man-pages) wrote:
>>> How about somethign like "This mount significantly reduces writes
>>> needed to update the inode's timestamps, especially mtime and actime.
>>
>> What is "actime" in the preceding line? Should it be "ctime"?
>
> Sorry, no, it should be "atime".
Thanks.
>> I find the wording of there a little confusing. Is the following
>> a correct rewrite:
>>
>> The advantage of MS_STRICTATIME | MS_LAZYTIME is that stat(2)
>> will return the correctly updated atime, but the atime updates
>> will be flushed to disk only when (1) the inode needs to be
>> updated for filesystem / data consistency reasons or (2) the
>> inode is pushed out of memory, or (3) the filesystem is
>> unmounted.)
>
> Yes, that's correct. The only other thing I might add is that in the
> case of a crash, the atime (or mtime) fields on disk might be out of
> date by at most 24 hours.
So in other words, add a sentence to that last para:
The disadvantage of MS_STRICTATIME | MS_LAZYTIME is that
in the case of a system crash, the atime and mtime fields
on disk might be out of date by at most 24 hours.
Right?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH v2] coresight-stm: adding driver for CoreSight STM component
From: Mathieu Poirier @ 2015-02-26 14:22 UTC (permalink / raw)
To: Shawn Guo
Cc: Jon Corbet, linux-arm-kernel@lists.infradead.org, linux-api,
linux-kernel@vger.kernel.org, linux-doc
In-Reply-To: <20150226055320.GA20385@dragon>
On 25 February 2015 at 22:53, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Wed, Feb 25, 2015 at 04:32:32PM -0700, Mathieu Poirier wrote:
>> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>> new file mode 100644
>> index 000000000000..3ddb676831ab
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>> @@ -0,0 +1,62 @@
>> +What: /sys/bus/coresight/devices/<memory_map>.stm/enable_source
>> +Date: February 2015
>> +KernelVersion: 3.20
>
> A random comment - there will never be a v3.20 kernel.
That's pretty funny! That part was obviously minted before there was
even an hint of moving to 4.0. Thanks for pointing it out.
>
> Shawn
>
>> +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
>> +Description: (RW) Enable/disable tracing on this specific trace macrocell.
>> + Enabling the trace macrocell implies it has been configured
>> + properly and a sink has been identidifed for it. The path
>> + of coresight components linking the source to the sink is
>> + configured and managed automatically by the coresight framework.
^ permalink raw reply
* Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework
From: Srinivas Kandagatla @ 2015-02-26 14:56 UTC (permalink / raw)
To: Maxime Ripard
Cc: Stephen Boyd, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, Pawel Moll, Kumar Gala,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Mark Brown, Greg Kroah-Hartman
In-Reply-To: <20150226132107.GH29241@lukather>
On 26/02/15 13:21, Maxime Ripard wrote:
> On Thu, Feb 26, 2015 at 09:16:27AM +0000, Srinivas Kandagatla wrote:
>> I think we are making simple eeprom framework too smart which will
>> break in future.
>>
>> IMHO, Anything on top of eeprom interface that interprets the data should
>> not go into the eeprom framework itself, it can either live some parsers/SOC
>> specific drivers/interfaces.
>
> True, but that doesn't mean that this parser support can't be built
> within the framework itself.
I was more of thinking parsers/interpreters as a layer on top of this
framework. Allowing the simplest users direct access to framework. Also
just eeprom_read() apis would not cater for all the parsers and I think
it would be very difficult to come up with abstracted consumer apis for
all the parsers which could be iterator or link-lists parsers or
something very different.
>
>> As Stephen pointed out earlier lets start with something like this, which
>> would provide a better abstraction to the discussed use cases like
>> serial-number and packed data in eeprom.
>>
>> qfprom@1000000 {
>> reg = <0x1000000 0x1000>;
>> ranges = <0 0x1000000 0x1000>;
>> compatible = "qcom,qfprom-msm8960"
>>
>> pvs-data: pvs-data@40 {
>> compatible = "qcom,pvs-a";
>> reg = <0x40 0x20>,
>> };
>>
>> tsens-data: tmdata@10 {
>> reg = <0x10 40>;
>> };
>>
>> serial-number: serial@50 {
>> compatible = "qcom,serial-msm8960";
>> reg = <0x50 4>, <0x60 4>;
>> };
>>
>> };
>
> And I'm sorry, but I still don't get why the compatibles are needed
> here.
This is an optional property, only purpose of this would be to serve as
parser/soc-specific identifier.
>
>> and then on the consumer side:
>>
>> device {
>> eeproms = <&serial-number>;
>> eeprom-names = "soc-rev-id";
>> };
>>
>> driver side:
>>
>> eeprom_get_cell()
>> eeprom_read();
>
> Looks good otherwise.
thanks
--srini
>
> Maxime
>
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 15:35 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge Hallyn, Serge E. Hallyn, Serge Hallyn, Andy Lutomirski,
Aaron Jones, Ted Ts'o, linux-security-module, akpm,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel, linux-api, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502251423580.13489@gentwo.org>
On Wed, Feb 25, 2015 at 02:25:19PM -0600, Christoph Lameter wrote:
> On Wed, 25 Feb 2015, Serge Hallyn wrote:
>
> > Yeah we could make this
>
> Well doing that breaks su.
Don't what exactly? You're saying that doing
pI' = pI
pA' = pA (pA is ambient)
pP' = (X & fP) | (pI & (fI | pA))
pE' = pP' & (fE | pA)
stopped su from having CAP_SETGID while
pI' = pI
pA' = pA (pA is ambient)
pP' = (X & fP) | (pI & (fI | pA))
pE' = pP' & fE
worked? I'll hope you're saying both "fail", in which case
> Its best to leave perm bits untouched.
> christoph@fujitsu-haswell:~$ su
> setgid: Operation not permitted
Did you initialize by running a program to fill your pI?
-serge
^ permalink raw reply
* [PATCH 3/3] Documentation/ABI: Add file describing the sysfs entries for toshiba_haps
From: Azael Avalos @ 2015-02-26 17:59 UTC (permalink / raw)
To: Darren Hart, platform-driver-x86-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
Cc: Azael Avalos
This patch adds a new file describing the sysfs entries for the
toshiba_haps driver.
Signed-off-by: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/ABI/testing/sysfs-driver-toshiba_haps | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-toshiba_haps
diff --git a/Documentation/ABI/testing/sysfs-driver-toshiba_haps b/Documentation/ABI/testing/sysfs-driver-toshiba_haps
new file mode 100644
index 0000000..a662370
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-toshiba_haps
@@ -0,0 +1,20 @@
+What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/protection_level
+Date: August 16, 2014
+KernelVersion: 3.17
+Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+Description: This file controls the built-in accelerometer protection level,
+ valid values are:
+ * 0 -> Disabled
+ * 1 -> Low
+ * 2 -> Medium
+ * 3 -> High
+ The default potection value is set to 2 (Medium).
+Users: KToshiba
+
+What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/reset_protection
+Date: August 16, 2014
+KernelVersion: 3.17
+Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+Description: This file turns off the built-in accelerometer for a few
+ seconds and then restore normal operation. Accepting 1 as the
+ only parameter.
--
2.2.2
^ permalink raw reply related
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 18:28 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module-u79uwXL29TY76Z2rM5mHXA,
akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <20150226153524.GC15182-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> > Well doing that breaks su.
>
> Don't what exactly? You're saying that doing
>
> pI' = pI
> pA' = pA (pA is ambient)
> pP' = (X & fP) | (pI & (fI | pA))
> pE' = pP' & (fE | pA)
>
> stopped su from having CAP_SETGID while
>
> pI' = pI
> pA' = pA (pA is ambient)
> pP' = (X & fP) | (pI & (fI | pA))
> pE' = pP' & fE
>
> worked? I'll hope you're saying both "fail", in which case
fE does not exist in cpu_vfs_cap_data. We only get fI and fP. Why in the
world does setcap allow setting fE?
V1 does not use fE. In my newer attempt, I seemed to have worked
with zeroed field that I assumed was filled in.
I will just do
pE' = pP'
Ok?
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 19:32 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Andy Lutomirski,
Aaron Jones, Ted Ts'o, linux-security-module, akpm,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel, linux-api, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502261224580.7451@gentwo.org>
On Thu, Feb 26, 2015 at 12:28:30PM -0600, Christoph Lameter wrote:
> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>
> > > Well doing that breaks su.
> >
> > Don't what exactly? You're saying that doing
> >
> > pI' = pI
> > pA' = pA (pA is ambient)
> > pP' = (X & fP) | (pI & (fI | pA))
> > pE' = pP' & (fE | pA)
> >
> > stopped su from having CAP_SETGID while
> >
> > pI' = pI
> > pA' = pA (pA is ambient)
> > pP' = (X & fP) | (pI & (fI | pA))
> > pE' = pP' & fE
> >
> > worked? I'll hope you're saying both "fail", in which case
>
> fE does not exist in cpu_vfs_cap_data. We only get fI and fP. Why in the
> world does setcap allow setting fE?
It sets a bit in the magic_etc. So fE is either all on or all off.
> V1 does not use fE. In my newer attempt, I seemed to have worked
> with zeroed field that I assumed was filled in.
>
> I will just do
>
> pE' = pP'
>
> Ok?
Andrew Morgan was against that. What if we changed
pE' = pP' & (fE | pA)
to
if (pA)
pE' = pP' & fE
else
pE' = pP'
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Andy Lutomirski @ 2015-02-26 19:38 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Christoph Lameter, Serge Hallyn, Serge Hallyn, Aaron Jones,
Ted Ts'o, LSM List, Andrew Morton, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel@vger.kernel.org, Linux API, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <20150226193200.GA17709@mail.hallyn.com>
On Thu, Feb 26, 2015 at 11:32 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> On Thu, Feb 26, 2015 at 12:28:30PM -0600, Christoph Lameter wrote:
>> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>>
>> > > Well doing that breaks su.
>> >
>> > Don't what exactly? You're saying that doing
>> >
>> > pI' = pI
>> > pA' = pA (pA is ambient)
>> > pP' = (X & fP) | (pI & (fI | pA))
>> > pE' = pP' & (fE | pA)
>> >
>> > stopped su from having CAP_SETGID while
>> >
>> > pI' = pI
>> > pA' = pA (pA is ambient)
>> > pP' = (X & fP) | (pI & (fI | pA))
>> > pE' = pP' & fE
>> >
>> > worked? I'll hope you're saying both "fail", in which case
>>
>> fE does not exist in cpu_vfs_cap_data. We only get fI and fP. Why in the
>> world does setcap allow setting fE?
>
> It sets a bit in the magic_etc. So fE is either all on or all off.
>
>> V1 does not use fE. In my newer attempt, I seemed to have worked
>> with zeroed field that I assumed was filled in.
>>
>> I will just do
>>
>> pE' = pP'
>>
>> Ok?
>
> Andrew Morgan was against that. What if we changed
>
> pE' = pP' & (fE | pA)
>
> to
>
> if (pA)
> pE' = pP' & fE
> else
> pE' = pP'
>
Is this backwards?
Also, on further bikeshedding consideration, I think I like the name
"persistent" much better than "ambient". Alas, "persistent" starts
with a P.
--Andy
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 20:13 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module-u79uwXL29TY76Z2rM5mHXA,
akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <20150226193200.GA17709-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> Andrew Morgan was against that. What if we changed
>
> pE' = pP' & (fE | pA)
>
> to
>
> if (pA)
> pE' = pP' & fE
> else
> pE' = pP'
>
Same problem as before. The ambient bits will not be set in pE'.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 20:16 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Aaron Jones,
Ted Ts'o, LSM List, Andrew Morton, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrWpKiurZEEOT25i_xrtQyk5dht+wjUO4+tGs+N_7JCdYA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 26 Feb 2015, Andy Lutomirski wrote:
> Also, on further bikeshedding consideration, I think I like the name
> "persistent" much better than "ambient". Alas, "persistent" starts
> with a P.
Ambient is like backround lighting. Its always there but barely visible.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 20:33 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge E. Hallyn, Christoph Lameter, Serge Hallyn, Serge Hallyn,
Aaron Jones, Ted Ts'o, LSM List, Andrew Morton,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel@vger.kernel.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrWpKiurZEEOT25i_xrtQyk5dht+wjUO4+tGs+N_7JCdYA@mail.gmail.com>
On Thu, Feb 26, 2015 at 11:38:01AM -0800, Andy Lutomirski wrote:
> On Thu, Feb 26, 2015 at 11:32 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Thu, Feb 26, 2015 at 12:28:30PM -0600, Christoph Lameter wrote:
> >> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> >>
> >> > > Well doing that breaks su.
> >> >
> >> > Don't what exactly? You're saying that doing
> >> >
> >> > pI' = pI
> >> > pA' = pA (pA is ambient)
> >> > pP' = (X & fP) | (pI & (fI | pA))
> >> > pE' = pP' & (fE | pA)
> >> >
> >> > stopped su from having CAP_SETGID while
> >> >
> >> > pI' = pI
> >> > pA' = pA (pA is ambient)
> >> > pP' = (X & fP) | (pI & (fI | pA))
> >> > pE' = pP' & fE
> >> >
> >> > worked? I'll hope you're saying both "fail", in which case
> >>
> >> fE does not exist in cpu_vfs_cap_data. We only get fI and fP. Why in the
> >> world does setcap allow setting fE?
> >
> > It sets a bit in the magic_etc. So fE is either all on or all off.
> >
> >> V1 does not use fE. In my newer attempt, I seemed to have worked
> >> with zeroed field that I assumed was filled in.
> >>
> >> I will just do
> >>
> >> pE' = pP'
> >>
> >> Ok?
> >
> > Andrew Morgan was against that. What if we changed
> >
> > pE' = pP' & (fE | pA)
> >
> > to
> >
> > if (pA)
> > pE' = pP' & fE
> > else
> > pE' = pP'
> >
>
> Is this backwards?
D'oh, yes.
> Also, on further bikeshedding consideration, I think I like the name
> "persistent" much better than "ambient". Alas, "persistent" starts
> with a P.
>
> --Andy
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 20:34 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Andy Lutomirski,
Aaron Jones, Ted Ts'o, linux-security-module, akpm,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel, linux-api, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502261412250.7451@gentwo.org>
On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote:
> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>
> > Andrew Morgan was against that. What if we changed
> >
> > pE' = pP' & (fE | pA)
> >
> > to
> >
> > if (pA)
> > pE' = pP' & fE
> > else
> > pE' = pP'
> >
>
> Same problem as before. The ambient bits will not be set in pE'.
And what if I weren't scatterbrained and we did
if (pA)
pE' = pP'
else
pE' = pP' & fE
All pP' bits would be set in pE'.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Andy Lutomirski @ 2015-02-26 20:51 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Christoph Lameter, Serge Hallyn, Serge Hallyn, Aaron Jones,
Ted Ts'o, LSM List, Andrew Morton, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel@vger.kernel.org, Linux API, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <20150226203405.GB18926@mail.hallyn.com>
On Thu, Feb 26, 2015 at 12:34 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote:
>> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>>
>> > Andrew Morgan was against that. What if we changed
>> >
>> > pE' = pP' & (fE | pA)
>> >
>> > to
>> >
>> > if (pA)
>> > pE' = pP' & fE
>> > else
>> > pE' = pP'
>> >
>>
>> Same problem as before. The ambient bits will not be set in pE'.
>
> And what if I weren't scatterbrained and we did
>
> if (pA)
> pE' = pP'
> else
> pE' = pP' & fE
>
> All pP' bits would be set in pE'.
That seems reasonable to me, except for my paranoia:
What if there's a program with CAP_DAC_OVERRIDE in fP and fE set to
the empty set (i.e. the magic effective bit cleared), and the program
relies on that. A malicious user has CAP_NET_BIND and sets pA =
CAP_NET_BIND. Boom!
If we changed that to if (pA') and zeroed pA if fP is non-empty then
this problem goes away.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 20:55 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge E. Hallyn, Christoph Lameter, Serge Hallyn, Serge Hallyn,
Aaron Jones, Ted Ts'o, LSM List, Andrew Morton,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel@vger.kernel.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrUB1bb4TiiBgdAMVtRJcEAoDzuOH+StTLPVL8QiXXdOfQ@mail.gmail.com>
On Thu, Feb 26, 2015 at 12:51:57PM -0800, Andy Lutomirski wrote:
> On Thu, Feb 26, 2015 at 12:34 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote:
> >> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> >>
> >> > Andrew Morgan was against that. What if we changed
> >> >
> >> > pE' = pP' & (fE | pA)
> >> >
> >> > to
> >> >
> >> > if (pA)
> >> > pE' = pP' & fE
> >> > else
> >> > pE' = pP'
> >> >
> >>
> >> Same problem as before. The ambient bits will not be set in pE'.
> >
> > And what if I weren't scatterbrained and we did
> >
> > if (pA)
> > pE' = pP'
> > else
> > pE' = pP' & fE
> >
> > All pP' bits would be set in pE'.
>
> That seems reasonable to me, except for my paranoia:
>
> What if there's a program with CAP_DAC_OVERRIDE in fP and fE set to
> the empty set (i.e. the magic effective bit cleared), and the program
> relies on that. A malicious user has CAP_NET_BIND and sets pA =
> CAP_NET_BIND. Boom!
>
> If we changed that to if (pA') and zeroed pA if fP is non-empty then
> this problem goes away.
Hm, the problem is that then the empty pA is inherited by children.
I do see that any program with fP set should probably run with only
what it requested. Would
if (pA && is_empty(fP))
pE' = pP'
else
pE' = pP' & fE
help? Or are you worried about a program with fP set which then
executes other programs?
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Andy Lutomirski @ 2015-02-26 20:58 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Christoph Lameter, Serge Hallyn, Serge Hallyn, Aaron Jones,
Ted Ts'o, LSM List, Andrew Morton, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <20150226205512.GA19273-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
On Thu, Feb 26, 2015 at 12:55 PM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, Feb 26, 2015 at 12:51:57PM -0800, Andy Lutomirski wrote:
>> On Thu, Feb 26, 2015 at 12:34 PM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
>> > On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote:
>> >> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>> >>
>> >> > Andrew Morgan was against that. What if we changed
>> >> >
>> >> > pE' = pP' & (fE | pA)
>> >> >
>> >> > to
>> >> >
>> >> > if (pA)
>> >> > pE' = pP' & fE
>> >> > else
>> >> > pE' = pP'
>> >> >
>> >>
>> >> Same problem as before. The ambient bits will not be set in pE'.
>> >
>> > And what if I weren't scatterbrained and we did
>> >
>> > if (pA)
>> > pE' = pP'
>> > else
>> > pE' = pP' & fE
>> >
>> > All pP' bits would be set in pE'.
>>
>> That seems reasonable to me, except for my paranoia:
>>
>> What if there's a program with CAP_DAC_OVERRIDE in fP and fE set to
>> the empty set (i.e. the magic effective bit cleared), and the program
>> relies on that. A malicious user has CAP_NET_BIND and sets pA =
>> CAP_NET_BIND. Boom!
>>
>> If we changed that to if (pA') and zeroed pA if fP is non-empty then
>> this problem goes away.
>
> Hm, the problem is that then the empty pA is inherited by children.
> I do see that any program with fP set should probably run with only
> what it requested. Would
>
> if (pA && is_empty(fP))
> pE' = pP'
> else
> pE' = pP' & fE
>
> help? Or are you worried about a program with fP set which then
> executes other programs?
The particular worry I expressed there was just about pE.
I'm still extremely nervous about allowing nonempty pA to propagate to
setuid or nonzero fP programs. It's less obviously dangerous if pA is
never a superset of pP, but it could still cause problems with setuid
programs that execute intentionally deprivileged helpers.
--Andy
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 21:09 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module, akpm, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel, linux-api, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <20150226203405.GB18926@mail.hallyn.com>
On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> > Same problem as before. The ambient bits will not be set in pE'.
>
> And what if I weren't scatterbrained and we did
>
> if (pA)
> pE' = pP'
> else
> pE' = pP' & fE
>
> All pP' bits would be set in pE'.
Ok and the non ambient case would break because fE is not available?
Doesnt this reduce to
pE' = pP'
in either case?
Here is a a patch that does just that. The patch works. Maybe I just dont
understand how this is supposed to work.
Subject: [PATCH] capabilities: Ambient capability set V2(draft)
V1->V2(draft):
- Modify bit calculations.
Signed-off-by: Christoph Lameter <cl@linux.com>
Index: linux/security/commoncap.c
===================================================================
--- linux.orig/security/commoncap.c 2015-02-25 13:43:06.929973954 -0600
+++ linux/security/commoncap.c 2015-02-26 12:36:32.361726374 -0600
@@ -347,15 +347,16 @@ static inline int bprm_caps_from_vfs_cap
*has_cap = true;
CAP_FOR_EACH_U32(i) {
+ __u32 ambient = current_cred()->cap_ambient.cap[i];
__u32 permitted = caps->permitted.cap[i];
__u32 inheritable = caps->inheritable.cap[i];
/*
- * pP' = (X & fP) | (pI & fI)
+ * pP' = (X & fP) | (pI & (fI | pA))
*/
new->cap_permitted.cap[i] =
(new->cap_bset.cap[i] & permitted) |
- (new->cap_inheritable.cap[i] & inheritable);
+ (new->cap_inheritable.cap[i] & (inheritable | ambient));
if (permitted & ~new->cap_permitted.cap[i])
/* insufficient to execute correctly */
@@ -453,8 +454,12 @@ static int get_file_caps(struct linux_bi
if (rc == -EINVAL)
printk(KERN_NOTICE "%s: get_vfs_caps_from_disk returned %d for %s\n",
__func__, rc, bprm->filename);
- else if (rc == -ENODATA)
+ else if (rc == -ENODATA) {
rc = 0;
+ /* The ambient caps are permitted for files that have no caps */
+ bprm->cred->cap_permitted = bprm->cred->cap_effective =
+ current_cred()->cap_ambient;
+ }
goto out;
}
@@ -548,10 +553,16 @@ skip:
new->suid = new->fsuid = new->euid;
new->sgid = new->fsgid = new->egid;
- if (effective)
- new->cap_effective = new->cap_permitted;
- else
- cap_clear(new->cap_effective);
+ /* pE' = pP' & (fE | pA)
+ new->cap_effective = cap_intersect(new->cap_permitted,
+ cap_combine(new->cap_effective, old->cap_ambient));
+ */
+
+ /* fE is not available */
+ new->cap_effective = new->cap_permitted;
+
+ /* pA' = pA */
+ new->cap_ambient = old->cap_ambient;
bprm->cap_effective = effective;
/*
@@ -566,7 +577,7 @@ skip:
* Number 1 above might fail if you don't have a full bset, but I think
* that is interesting information to audit.
*/
- if (!cap_isclear(new->cap_effective)) {
+ if (!cap_issubset(new->cap_effective, new->cap_ambient)) {
if (!cap_issubset(CAP_FULL_SET, new->cap_effective) ||
!uid_eq(new->euid, root_uid) || !uid_eq(new->uid, root_uid) ||
issecure(SECURE_NOROOT)) {
@@ -598,7 +609,7 @@ int cap_bprm_secureexec(struct linux_bin
if (!uid_eq(cred->uid, root_uid)) {
if (bprm->cap_effective)
return 1;
- if (!cap_isclear(cred->cap_permitted))
+ if (!cap_issubset(cred->cap_permitted, cred->cap_ambient))
return 1;
}
@@ -933,6 +944,23 @@ int cap_task_prctl(int option, unsigned
new->securebits &= ~issecure_mask(SECURE_KEEP_CAPS);
return commit_creds(new);
+ case PR_CAP_AMBIENT:
+ if (!ns_capable(current_user_ns(), CAP_SETPCAP))
+ return -EPERM;
+
+ if (!cap_valid(arg2))
+ return -EINVAL;
+
+ if (!ns_capable(current_user_ns(), arg2))
+ return -EPERM;
+
+ new = prepare_creds();
+ if (arg3 == 0)
+ cap_lower(new->cap_ambient, arg2);
+ else
+ cap_raise(new->cap_ambient, arg2);
+ return commit_creds(new);
+
default:
/* No functionality available - continue with default */
return -ENOSYS;
Index: linux/include/linux/cred.h
===================================================================
--- linux.orig/include/linux/cred.h 2015-02-25 13:43:06.929973954 -0600
+++ linux/include/linux/cred.h 2015-02-25 13:43:06.925972078 -0600
@@ -122,6 +122,7 @@ struct cred {
kernel_cap_t cap_permitted; /* caps we're permitted */
kernel_cap_t cap_effective; /* caps we can actually use */
kernel_cap_t cap_bset; /* capability bounding set */
+ kernel_cap_t cap_ambient; /* Ambient capability set */
#ifdef CONFIG_KEYS
unsigned char jit_keyring; /* default keyring to attach requested
* keys to */
Index: linux/include/uapi/linux/prctl.h
===================================================================
--- linux.orig/include/uapi/linux/prctl.h 2015-02-25 13:43:06.929973954 -0600
+++ linux/include/uapi/linux/prctl.h 2015-02-25 13:43:06.925972078 -0600
@@ -185,4 +185,7 @@ struct prctl_mm_map {
#define PR_MPX_ENABLE_MANAGEMENT 43
#define PR_MPX_DISABLE_MANAGEMENT 44
+/* Control the ambient capability set */
+#define PR_CAP_AMBIENT 45
+
#endif /* _LINUX_PRCTL_H */
Index: linux/fs/proc/array.c
===================================================================
--- linux.orig/fs/proc/array.c 2015-02-25 13:43:06.929973954 -0600
+++ linux/fs/proc/array.c 2015-02-25 13:43:06.925972078 -0600
@@ -302,7 +302,8 @@ static void render_cap_t(struct seq_file
static inline void task_cap(struct seq_file *m, struct task_struct *p)
{
const struct cred *cred;
- kernel_cap_t cap_inheritable, cap_permitted, cap_effective, cap_bset;
+ kernel_cap_t cap_inheritable, cap_permitted, cap_effective,
+ cap_bset, cap_ambient;
rcu_read_lock();
cred = __task_cred(p);
@@ -310,12 +311,14 @@ static inline void task_cap(struct seq_f
cap_permitted = cred->cap_permitted;
cap_effective = cred->cap_effective;
cap_bset = cred->cap_bset;
+ cap_ambient = cred->cap_ambient;
rcu_read_unlock();
render_cap_t(m, "CapInh:\t", &cap_inheritable);
render_cap_t(m, "CapPrm:\t", &cap_permitted);
render_cap_t(m, "CapEff:\t", &cap_effective);
render_cap_t(m, "CapBnd:\t", &cap_bset);
+ render_cap_t(m, "CapAmb:\t", &cap_ambient);
}
static inline void task_seccomp(struct seq_file *m, struct task_struct *p)
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 21:13 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Andy Lutomirski,
Aaron Jones, Ted Ts'o,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502261507450.8274-gkYfJU5Cukgdnm+yROfE0A@public.gmane.org>
On Thu, Feb 26, 2015 at 03:09:48PM -0600, Christoph Lameter wrote:
> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>
> > > Same problem as before. The ambient bits will not be set in pE'.
> >
> > And what if I weren't scatterbrained and we did
> >
> > if (pA)
> > pE' = pP'
> > else
> > pE' = pP' & fE
> >
> > All pP' bits would be set in pE'.
>
> Ok and the non ambient case would break because fE is not available?
> Doesnt this reduce to
>
> pE' = pP'
>
> in either case?
No. fE is not "not available". If you set it with setcap, you *should*
(if i'm tinking right) find fE full when calculating the new capability
sets, because of magic_etc.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 21:19 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge E. Hallyn, Christoph Lameter, Serge Hallyn, Serge Hallyn,
Aaron Jones, Ted Ts'o, LSM List, Andrew Morton,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel@vger.kernel.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrXGO+ejHAfic4fozf1y48WDBdk3Mo=dFt8MMxtN1HOuUg@mail.gmail.com>
On Thu, Feb 26, 2015 at 12:58:33PM -0800, Andy Lutomirski wrote:
> On Thu, Feb 26, 2015 at 12:55 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Thu, Feb 26, 2015 at 12:51:57PM -0800, Andy Lutomirski wrote:
> >> On Thu, Feb 26, 2015 at 12:34 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> >> > On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote:
> >> >> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> >> >>
> >> >> > Andrew Morgan was against that. What if we changed
> >> >> >
> >> >> > pE' = pP' & (fE | pA)
> >> >> >
> >> >> > to
> >> >> >
> >> >> > if (pA)
> >> >> > pE' = pP' & fE
> >> >> > else
> >> >> > pE' = pP'
> >> >> >
> >> >>
> >> >> Same problem as before. The ambient bits will not be set in pE'.
> >> >
> >> > And what if I weren't scatterbrained and we did
> >> >
> >> > if (pA)
> >> > pE' = pP'
> >> > else
> >> > pE' = pP' & fE
> >> >
> >> > All pP' bits would be set in pE'.
> >>
> >> That seems reasonable to me, except for my paranoia:
> >>
> >> What if there's a program with CAP_DAC_OVERRIDE in fP and fE set to
> >> the empty set (i.e. the magic effective bit cleared), and the program
> >> relies on that. A malicious user has CAP_NET_BIND and sets pA =
> >> CAP_NET_BIND. Boom!
> >>
> >> If we changed that to if (pA') and zeroed pA if fP is non-empty then
> >> this problem goes away.
> >
> > Hm, the problem is that then the empty pA is inherited by children.
> > I do see that any program with fP set should probably run with only
> > what it requested. Would
> >
> > if (pA && is_empty(fP))
> > pE' = pP'
> > else
> > pE' = pP' & fE
> >
> > help? Or are you worried about a program with fP set which then
> > executes other programs?
>
> The particular worry I expressed there was just about pE.
>
> I'm still extremely nervous about allowing nonempty pA to propagate to
> setuid or nonzero fP programs. It's less obviously dangerous if pA is
> never a superset of pP, but it could still cause problems with setuid
> programs that execute intentionally deprivileged helpers.
I don't think that what you want is compatible with what Christoph
wants. (He also thinks that what I want is not compatible with what
he wants, but I still think it is)
The approach I'm taking is that pA is useless if pI is not set. For
a privileged program to fill its pI is a pretty special thing now,
so this shouldn't be catching anyone by surprise. Furthermore,
the privileged program which is filling both its pI and pA
and then executing other files could achieve the same result
by filling pI and setting file capaiblities on all executables.
Setting pA gives them a different tradeoff (limiting the
capabilities trust to its process tree, but to all binaries)
which should do what Christoph wants. By limiting the effective pA to fP
if fP is not empty, we'r eonly prevneting the file which
had fP set from running in an unexpected way which should be
safer. (But if it executes another file, that file, it will
receive the original pA)
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 21:23 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module, akpm, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel, linux-api, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <20150226211324.GB19273@mail.hallyn.com>
On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> No. fE is not "not available". If you set it with setcap, you *should*
> (if i'm tinking right) find fE full when calculating the new capability
> sets, because of magic_etc.
There is nothing in get_vfs_caps_from_disk that does this and the magic
vanishes after this function is done.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 21:29 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Aaron Jones,
Ted Ts'o, LSM List, Andrew Morton, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel@vger.kernel.org, Linux API, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <CALCETrXGO+ejHAfic4fozf1y48WDBdk3Mo=dFt8MMxtN1HOuUg@mail.gmail.com>
On Thu, 26 Feb 2015, Andy Lutomirski wrote:
> I'm still extremely nervous about allowing nonempty pA to propagate to
> setuid or nonzero fP programs. It's less obviously dangerous if pA is
> never a superset of pP, but it could still cause problems with setuid
> programs that execute intentionally deprivileged helpers.
Well but the intend of the ambient caps is that all processes spawned have
those caps. So they should not be dropped implicitly by othe mechanisms
because they could spawn scripts etc that need these privs again.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 21:32 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Andy Lutomirski,
Aaron Jones, Ted Ts'o, linux-security-module, akpm,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel, linux-api, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502261522300.8444@gentwo.org>
On Thu, Feb 26, 2015 at 03:23:35PM -0600, Christoph Lameter wrote:
> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>
> > No. fE is not "not available". If you set it with setcap, you *should*
> > (if i'm tinking right) find fE full when calculating the new capability
> > sets, because of magic_etc.
>
> There is nothing in get_vfs_caps_from_disk that does this and the magic
> vanishes after this function is done.
get_vfs_caps_from_disk does:
cpu_caps->magic_etc = magic_etc = le32_to_cpu(caps.magic_etc);
then bprm_caps_from_vfs_caps does:
if (caps->magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
*effective = true;
and finally cap_bprm_set_creds does:
if (effective)
new->cap_effective = new->cap_permitted;
else
cap_clear(new->cap_effective);
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 21:37 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module, akpm, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel, linux-api, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <20150226213236.GA19753@mail.hallyn.com>
On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> > There is nothing in get_vfs_caps_from_disk that does this and the magic
> > vanishes after this function is done.
>
> get_vfs_caps_from_disk does:
>
> cpu_caps->magic_etc = magic_etc = le32_to_cpu(caps.magic_etc);
>
> then bprm_caps_from_vfs_caps does:
>
> if (caps->magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
> *effective = true;
Ahhh.. I was wondering what that is.
> and finally cap_bprm_set_creds does:
>
> if (effective)
> new->cap_effective = new->cap_permitted;
> else
> cap_clear(new->cap_effective);
Ok. I took that out thats why it worked.
^ permalink raw reply
* Re: [PATCH 2/2] fbcon: expose cursor blink interval via sysfs
From: Pavel Machek @ 2015-02-26 22:02 UTC (permalink / raw)
To: Scot Doyle
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Geert Uytterhoeven, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.LNX.2.11.1502252319330.276@localhost>
On Wed 2015-02-25 23:32:00, Scot Doyle wrote:
> On Wed, 25 Feb 2015, Pavel Machek wrote:
> > On Mon 2015-01-26 20:41:53, Scot Doyle wrote:
> > > The fbcon cursor, when set to blink, is hardcoded to toggle display state
> > > five times per second. Expose this setting via
> > > /sys/class/graphics/fbcon/cursor_blink_ms
> > >
> > > Values written to the interface set the approximate time interval in
> > > milliseconds between cursor toggles, from 1 to 32767. Since the interval
> > > is stored internally as a number of jiffies, the millisecond value read
> > > from the interface may not exactly match the entered value.
> > >
> > > An outstanding blink timer is reset after a new value is entered.
> > >
> > > If the cursor blink is disabled, either via the 'cursor_blink' boolean
> > > setting or some other mechanism, the 'cursor_blink_ms' setting may still
> > > be modified. The new value will be used if the blink is reactivated.
> > >
> > > Signed-off-by: Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org>
> >
> > Normally, this would be set by ansi escape sequences, no? We can hide
> > cursor using them, set its appearance.. makes sense to change timing
> > value there, too....
> > Pavel
>
> Hi Pavel, what about something like this? For example,
> "echo -e '\033[16;500]' would set the blink interval to 500 milliseconds.
>
> The duration is stored twice to avoid locking the console in
> cursor_timer_handler().
Yes, I'd say this matches the existing code better.
Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
> + case 16: /* set cursor blink duration in msec */
> + if (vc->vc_npar >= 1 && vc->vc_par[1] > 0 &&
> + vc->vc_par[1] <= USHRT_MAX)
> + vc->vc_cur_blink_ms = vc->vc_par[1];
> + else
Actually, vc_cur_blink_ms less then about 50 probably does not make
sense (and may overload the system). Should that be checked?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox