RE: ALSA problems.

[Dan Thurman]

Eric Paris wrote:
> what problems are you having, why do you believe this is an selinux
> issue, please, tell us what is happening, what you are seeing and
> provide output of errors?  If this is selinux you will find message in
> either /var/log/messages or /var/log/audit/audit.log which will be most
> interesting to the people on this list.
>
> -Eric
>
> >Daniel B. Thurman wrote:
> > I was forced to install ALSA manually in my F8 system and 
> unfortunately,
> > I discovered that setting /.autorelabel did not correctly 
> set ALSA permissions.
> > 
> > I did note that a bug report was filed for this.
> > 
> > Meanwhile, I would like a solution to solve my issue, if 
> there is one?
> > 
> > Kind regards,
> > Dan
> >  
This is something I just found when searching the /var/log/message file
but this is not related to ALSA, but to rhgb:

Jan  7 13:11:44 localhost kernel: audit(1199740241.970:9): avc:  denied  { read write }
for  pid=1775 comm="consoletype" path="/dev/pts/0" dev=devpts ino=2
scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:rhgb_devpts_t:s0
tclass=chr_file

As for ALSA issues, there was a problem writing to /etc/asound.state and to ~/.asoundrc
but this is not recorded where I can find it.  It only happens during logoff/shutdown
and I see it very briefly and it appears to be an 'alsactl store' command failure
and
*maybe* the log below is related to it but I cannot confirm it.

Jan  8 12:28:30 gold kernel: audit(1199823854.622:4): avc:  denied  { getattr } for 
pid=1264 comm="salsa" path="/usr/share/alsa/alsa.conf" dev=sda5
ino=147458 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023
tcontext=system_u:object_r:usr_t:s0 tclass=file

I DO know that alsactl is not able to set the volume control settings for which
I am forced to reset every time at login after a boot.  There was some months
ago that Daniel Walsh wrote as a bug report in getting the /etc/asound.state
moved to /var/lib directory and it was written on Sept 17, 2007.


No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.17.13/1213 - Release Date: 1/7/2008 9:14 AM

ALSA problems.

[Dan Thurman]

On Tuesday 08 January 2008 03:58:20 pm Daniel B. Thurman wrote:
>  Eric Paris wrote:
>  >what problems are you having, why do you believe this is an selinux
>  >issue, please, tell us what is happening, what you are seeing and
>  >provide output of errors?  If this is selinux you will find message in
>  >either /var/log/messages or /var/log/audit/audit.log which will be most
>  >interesting to the people on this list.
>  >
>  >-Eric
>  >
>  >>Daniel B. Thurman wrote:
>  >> I was forced to install ALSA manually in my F8 system and
>  >
>  >unfortunately,
>  >
>  >> I discovered that setting /.autorelabel did not correctly
>  >
>  >set ALSA permissions.
>  >
>  >> I did note that a bug report was filed for this.
>  >>
>  >> Meanwhile, I would like a solution to solve my issue, if
>  >
>  >there is one?
>  >
>  >> Kind regards,
>  >> Dan
>
>  This is something I just found when searching the /var/log/message file
>  but this is not related to ALSA, but to rhgb:
>  Jan  7 13:11:44 localhost kernel: audit(1199740241.970:9): avc:  denied  {
>  read write } for  pid=1775 comm="consoletype" path="/dev/pts/0"
> dev=devpts
>  ino=2 scontext=system_u:system_r:consoletype_t:s0
>  tcontext=system_u:object_r:rhgb_devpts_t:s0 tclass=chr_file As for ALSA
>  issues, there was a problem writing to /etc/asound.state and to ~/.asoundrc
>  but this is not recorded where I can find it.  It only happens during
>  logoff/shutdown and I see it very briefly and it appears to be an 'alsactl
>  store' command failure and *maybe* the log below is related to it but I
>  cannot confirm it.
>  Jan  8 12:28:30 gold kernel: audit(1199823854.622:4): avc:  denied  {
>  getattr } for  pid=1264 comm="salsa"
> path="/usr/share/alsa/alsa.conf"
>  dev=sda5 ino=147458 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023
>  tcontext=system_u:object_r:usr_t:s0 tclass=file I DO know that alsactl is
>  not able to set the volume control settings for which I am forced to reset
>  every time at login after a boot.  There was some months ago that Daniel
>  Walsh wrote as a bug report in getting the /etc/asound.state moved to
>  /var/lib directory and it was written on Sept 17, 2007.
>  
Is there any resolution to this issue?  Seems that no one is responding
as to what I can to do try to analyze or to fix this issue?

ALSA problems.

[Max]

--- Dan Thurman <dant(a)cdkkt.com&gt; wrote:

>  On Tuesday 08 January 2008 03:58:20 pm Daniel B. Thurman wrote:
>  > Eric Paris wrote:
>  > >what problems are you having, why do you believe this is an selinux
>  > >issue, please, tell us what is happening, what you are seeing and
>  > >provide output of errors?  If this is selinux you will find message in
>  > >either /var/log/messages or /var/log/audit/audit.log which will be most
>  > >interesting to the people on this list.
>  > >
>  > >-Eric
>  > >
>  > >>Daniel B. Thurman wrote:
>  > >> I was forced to install ALSA manually in my F8 system and
>  > >
>  > >unfortunately,
>  > >
>  > >> I discovered that setting /.autorelabel did not correctly
>  > >
>  > >set ALSA permissions.
>  > >
>  > >> I did note that a bug report was filed for this.
>  > >>
>  > >> Meanwhile, I would like a solution to solve my issue, if
>  > >
>  > >there is one?
>  > >
>  > >> Kind regards,
>  > >> Dan
>  >
>  > This is something I just found when searching the /var/log/message file
>  > but this is not related to ALSA, but to rhgb:
>  > Jan  7 13:11:44 localhost kernel: audit(1199740241.970:9): avc:  denied  {
>  > read write } for  pid=1775 comm="consoletype" path="/dev/pts/0"
> dev=devpts
>  > ino=2 scontext=system_u:system_r:consoletype_t:s0
>  > tcontext=system_u:object_r:rhgb_devpts_t:s0 tclass=chr_file As for ALSA
>  > issues, there was a problem writing to /etc/asound.state and to ~/.asoundrc
>  > but this is not recorded where I can find it.  It only happens during
>  > logoff/shutdown and I see it very briefly and it appears to be an 'alsactl
>  > store' command failure and *maybe* the log below is related to it but I
>  > cannot confirm it.
>  > Jan  8 12:28:30 gold kernel: audit(1199823854.622:4): avc:  denied  {
>  > getattr } for  pid=1264 comm="salsa"
> path="/usr/share/alsa/alsa.conf"
>  > dev=sda5 ino=147458 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023
>  > tcontext=system_u:object_r:usr_t:s0 tclass=file I DO know that alsactl is
>  > not able to set the volume control settings for which I am forced to reset
>  > every time at login after a boot.  There was some months ago that Daniel
>  > Walsh wrote as a bug report in getting the /etc/asound.state moved to
>  > /var/lib directory and it was written on Sept 17, 2007.
>  >
>  
>  Is there any resolution to this issue?  Seems that no one is responding
>  as to what I can to do try to analyze or to fix this issue?
>   
I am resisting the temptation to quote YODA!


     
____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search. 
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

[F8] ALSA problems. [SOLVED]

[Dan Thurman]

Problem solved. Solution was to remove all alsa packages 
using 'rpm -e --justdb --nodeps <alsa-packages>', manually
delete /etc/alsa and /usr/share/alsa. and then re-install the latest
yum updates.

Sorry for wasting your time.

[F8] ALSA problems. [SOLVED]

[Max]

--- Dan Thurman <dant(a)cdkkt.com&gt; wrote:

>  
>  Problem solved. Solution was to remove all alsa packages 
>  using 'rpm -e --justdb --nodeps <alsa-packages>', manually
>  delete /etc/alsa and /usr/share/alsa. and then re-install the latest
>  yum updates.
>  
>  Sorry for wasting your time. 
I don't think there is anything to apologize for,
after all that's what makes the list useful. It
is a sounding board of sorts. After all no one is required to reply. Glad you got it
working.

-Max



     
____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Problem with samba mounts via fstab and credentials option

[Dan Thurman]

When one adds a samba share via /etc/fstab and using as an entry:

credentials=/etc/share/auth.smb in the options field

This file contains sensitive username/password data, has a samba_etc_t type 
but on reboot, SELinux does not allow the mount.cifs program to read fstab 
entries containing the credentials mount options and produces an error 13 
message during the loading of the services. The result is that the mount has 
failed and must be remounted manually as a root user after the system comes 
up.

The logs show:

type=AVC msg=audit(1200012700.796:14): avc:  denied  { read } for 
pid=2528 comm="mount.cifs" name="auth.smb" dev=sda5 ino=788340
scontext=system_u:system_r:mount_t:s0 
tcontext=system_u:object_r:samba_etc_t:s0 tclass=file

Should I simply attempt to chcon -t mount_t /etc/samba.auth.smb or should this 
be handled differently?

Thanks-
Dan

Problem with samba mounts via fstab and credentials option

[Dan Thurman]

On Thursday 10 January 2008 05:06:51 pm Daniel B. Thurman wrote:
>  When one adds a samba share via /etc/fstab and using as an entry:
>  credentials=/etc/share/auth.smb in the options field
>  This file contains sensitive username/password data, has a samba_etc_t type
>  but on reboot, SELinux does not allow the mount.cifs program to read fstab
>  entries containing the credentials mount options and produces an error 13
>  message during the loading of the services. The result is that the mount
>  has failed and must be remounted manually as a root user after the system
>  comes up.
>  The logs show:
>  type=AVC msg=audit(1200012700.796:14): avc:  denied  { read } for
>  pid=2528 comm="mount.cifs" name="auth.smb" dev=sda5 ino=788340
>  scontext=system_u:system_r:mount_t:s0
>  tcontext=system_u:object_r:samba_etc_t:s0 tclass=file
>  Should I simply attempt to chcon -t mount_t /etc/samba.auth.smb or should
>  this be handled differently?
>  Thanks-
>  Dan 
Oops.  It should have said: /etc/samba/auth.smb

Problem with samba mounts via fstab and credentials option

[Paul Howarth]

Dan Thurman wrote:
>  On Thursday 10 January 2008 05:06:51 pm Daniel B. Thurman wrote:
> > When one adds a samba share via /etc/fstab and using as an entry:
> > credentials=/etc/share/auth.smb in the options field
> > This file contains sensitive username/password data, has a samba_etc_t type
> > but on reboot, SELinux does not allow the mount.cifs program to read fstab
> > entries containing the credentials mount options and produces an error 13
> > message during the loading of the services. The result is that the mount
> > has failed and must be remounted manually as a root user after the system
> > comes up.
> > The logs show:
> > type=AVC msg=audit(1200012700.796:14): avc:  denied  { read } for
> > pid=2528 comm="mount.cifs" name="auth.smb" dev=sda5 ino=788340
> > scontext=system_u:system_r:mount_t:s0
> > tcontext=system_u:object_r:samba_etc_t:s0 tclass=file
> > Should I simply attempt to chcon -t mount_t /etc/samba.auth.smb or should
> > this be handled differently?
> > Thanks-
> > Dan
>  
>  Oops.  It should have said: /etc/samba/auth.smb 
Try setting the allow_mount_anyfile boolean.

# setsebool -P allow_mount_anyfile 1

Paul.