long story short: in updating to a slightly newer hand-rolled
kernel (2.6.39-rc7 -> 3.0.0-rc3) on my ubuntu system, i somehow (no
idea how) managed to deselect CONFIG_TMPFS_POSIX_ACL without realizing
it. the consequences of this were that sound suddenly disappeared
under the new kernel, for a fairly obvious reason -- ALSA needs ACLs
under /dev to give R/W access to the user to the device files under
/dev/snd/.
as i said, i have no idea how i managed to do this but i eventually
tracked it down, re-selected that option, rebuilt and i have sound
again. but i noticed that in fs/Kconfig, that option is independently
selectable from TMPFS, so it's (as i learned) deviously easy to
deselect, with annoying consequences.
more to the point, given the apparent necessity of ACLs under /dev
for proper sound operation, the help info for that option seems a bit
misleading:
config TMPFS_POSIX_ACL
bool "Tmpfs POSIX Access Control Lists"
depends on TMPFS
select TMPFS_XATTR
select GENERIC_ACL
help
... snip ...
If you don't know what Access Control Lists are, say N.
yeah, i think that help line might not want to dismiss tmpfs ACLs
quite so quickly. thoughts?
rday
p.s. i do notice a fairly recent change to that config file related
to this:
commit 4db70f73e56961b9bcdfd0c36c62847a18b7dbb5
Author: Eric Paris <[email protected]>
Date: Wed May 25 19:49:18 2011 -0700
tmpfs: fix XATTR N overriding POSIX_ACL Y
Choosing TMPFS_XATTR default N was switching off TMPFS_POSIX_ACL,
even if it had been Y in oldconfig; and Linus reports that PulseAudio
goes subtly wrong unless it can use ACLs on /dev/shm.
Make TMPFS_POSIX_ACL select TMPFS_XATTR (and depend upon TMPFS),
and move the TMPFS_POSIX_ACL entry before the TMPFS_XATTR entry,
to avoid asking unnecessary questions then ignoring their answers.
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
On Fri, 17 Jun 2011, Robert P. J. Day wrote:
>
> long story short: in updating to a slightly newer hand-rolled
> kernel (2.6.39-rc7 -> 3.0.0-rc3) on my ubuntu system, i somehow (no
> idea how) managed to deselect CONFIG_TMPFS_POSIX_ACL without realizing
> it. the consequences of this were that sound suddenly disappeared
> under the new kernel, for a fairly obvious reason -- ALSA needs ACLs
> under /dev to give R/W access to the user to the device files under
> /dev/snd/.
>
> as i said, i have no idea how i managed to do this but i eventually
> tracked it down, re-selected that option, rebuilt and i have sound
> again. but i noticed that in fs/Kconfig, that option is independently
> selectable from TMPFS, so it's (as i learned) deviously easy to
> deselect, with annoying consequences.
>
> more to the point, given the apparent necessity of ACLs under /dev
> for proper sound operation, the help info for that option seems a bit
> misleading:
>
> config TMPFS_POSIX_ACL
> bool "Tmpfs POSIX Access Control Lists"
> depends on TMPFS
> select TMPFS_XATTR
> select GENERIC_ACL
> help
> ... snip ...
> If you don't know what Access Control Lists are, say N.
>
> yeah, i think that help line might not want to dismiss tmpfs ACLs
> quite so quickly. thoughts?
>
> rday
>
> p.s. i do notice a fairly recent change to that config file related
> to this:
Yes, we were originally losing the oldconfig value of TMPFS_POSIX_ACL.
It would be easy to ack a patch from you which changes that wording
"If you don't know what Access Control Lists are, say N" to something
more informative about what the sound userspace wants.
It would be harder to justify having SOUND select TMPFS, or changing
the TMPFS_POSIX_ACL default to Y. It's been N forever, and that is
how we prefer to add features.
Hugh
>
> commit 4db70f73e56961b9bcdfd0c36c62847a18b7dbb5
> Author: Eric Paris <[email protected]>
> Date: Wed May 25 19:49:18 2011 -0700
>
> tmpfs: fix XATTR N overriding POSIX_ACL Y
>
> Choosing TMPFS_XATTR default N was switching off TMPFS_POSIX_ACL,
> even if it had been Y in oldconfig; and Linus reports that PulseAudio
> goes subtly wrong unless it can use ACLs on /dev/shm.
>
> Make TMPFS_POSIX_ACL select TMPFS_XATTR (and depend upon TMPFS),
> and move the TMPFS_POSIX_ACL entry before the TMPFS_XATTR entry,
> to avoid asking unnecessary questions then ignoring their answers.
>
>
> --
On Fri, 17 Jun 2011, Hugh Dickins wrote:
> On Fri, 17 Jun 2011, Robert P. J. Day wrote:
> >
> > long story short: in updating to a slightly newer hand-rolled
> > kernel (2.6.39-rc7 -> 3.0.0-rc3) on my ubuntu system, i somehow (no
> > idea how) managed to deselect CONFIG_TMPFS_POSIX_ACL without realizing
> > it. the consequences of this were that sound suddenly disappeared
> > under the new kernel, for a fairly obvious reason -- ALSA needs ACLs
> > under /dev to give R/W access to the user to the device files under
> > /dev/snd/.
> >
> > as i said, i have no idea how i managed to do this but i eventually
> > tracked it down, re-selected that option, rebuilt and i have sound
> > again. but i noticed that in fs/Kconfig, that option is independently
> > selectable from TMPFS, so it's (as i learned) deviously easy to
> > deselect, with annoying consequences.
> >
> > more to the point, given the apparent necessity of ACLs under /dev
> > for proper sound operation, the help info for that option seems a bit
> > misleading:
> >
> > config TMPFS_POSIX_ACL
> > bool "Tmpfs POSIX Access Control Lists"
> > depends on TMPFS
> > select TMPFS_XATTR
> > select GENERIC_ACL
> > help
> > ... snip ...
> > If you don't know what Access Control Lists are, say N.
> >
> > yeah, i think that help line might not want to dismiss tmpfs ACLs
> > quite so quickly. thoughts?
> >
> > rday
> >
> > p.s. i do notice a fairly recent change to that config file related
> > to this:
>
> Yes, we were originally losing the oldconfig value of
> TMPFS_POSIX_ACL.
>
> It would be easy to ack a patch from you which changes that wording
> "If you don't know what Access Control Lists are, say N" to
> something more informative about what the sound userspace wants.
agreed -- something as simple as "if you don't know, say Y"? :-)
or would it be better to actually take a line or two to explain the
consequences of that option? (by the way, this option affects more
than just sound.)
> It would be harder to justify having SOUND select TMPFS, or changing
> the TMPFS_POSIX_ACL default to Y. It's been N forever, and that is
> how we prefer to add features.
normally, i'd agree with you, except for the observation that, by
far, the default config files across all architectures select that
option. there are 48 config files that select it, and only 3 that
don't. sometimes, that's a compelling argument that maybe it *should*
be default yes. but for now, i'll just whip up a more informative
help sentence or two.
rday
p.s. as i mentioned, that option would appear to affect more than
just sound. as in:
$ getfacl /dev/kvm
getfacl: Removing leading '/' from absolute path names
# file: dev/kvm
# owner: root
# group: kvm
user::rw-
user:rpjday:rw-
group::rw-
mask::rw-
other::---
so wouldn't KVM suddenly start behaving badly as well?
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
On Fri, 17 Jun 2011, Robert P. J. Day wrote:
> On Fri, 17 Jun 2011, Hugh Dickins wrote:
> > On Fri, 17 Jun 2011, Robert P. J. Day wrote:
> > >
> > > p.s. i do notice a fairly recent change to that config file related
> > > to this:
> >
> > Yes, we were originally losing the oldconfig value of
> > TMPFS_POSIX_ACL.
> >
> > It would be easy to ack a patch from you which changes that wording
> > "If you don't know what Access Control Lists are, say N" to
> > something more informative about what the sound userspace wants.
>
> agreed -- something as simple as "if you don't know, say Y"? :-)
> or would it be better to actually take a line or two to explain the
> consequences of that option?
I think both. I've often thought "default N", "if unsure say Y"
Kconfig options contradictory, but I can see the point in this case.
Example or examples of the pain of saying N can be helpful.
> (by the way, this option affects more than just sound.)
Of course.
>
> > It would be harder to justify having SOUND select TMPFS, or changing
> > the TMPFS_POSIX_ACL default to Y. It's been N forever, and that is
> > how we prefer to add features.
>
> normally, i'd agree with you, except for the observation that, by
> far, the default config files across all architectures select that
> option. there are 48 config files that select it, and only 3 that
> don't. sometimes, that's a compelling argument that maybe it *should*
> be default yes. but for now, i'll just whip up a more informative
> help sentence or two.
I don't think architecture defconfig files necessarily correlate with
Kconfig defaults. You could argue that they should do so (so far as
arch-independent options are concerned), but I think the reality is
that arch defconfigs are produced separately, at the whim of various
people with different agendas. I may be wrong (if unsure, say Y!).
>
> rday
>
> p.s. as i mentioned, that option would appear to affect more than
> just sound. as in:
>
> $ getfacl /dev/kvm
> getfacl: Removing leading '/' from absolute path names
> # file: dev/kvm
> # owner: root
> # group: kvm
> user::rw-
> user:rpjday:rw-
> group::rw-
> mask::rw-
> other::---
>
> so wouldn't KVM suddenly start behaving badly as well?
Dunno. But certainly TMPFS_POSIX_ACLs are for whatever uses
tmpfs POSIX ACLs are being put to, not specific to sound - but
sound happens to be the case that wasted your time and Linus's.
Hugh