Discussion:
SMACK Labels for /dev/snd/*
(too old to reply)
Zaman, Imran
2014-12-15 11:18:26 UTC
Permalink
Hei!

Recently we have encountered an issue that if a PAM user session has PAM_TTY set as "tty1", then it sets appropriate smack labels for /dev/snd/*.
otherwise the smack labels are not set appropriately for any other value and the devices become inaccessible.

Can someone please indicate,
a- Which component is responsible for setting up the smack lables for /dev/snd/* on the fly? Is it systemd?
b- Why is it hard-coded such that if PAM session has PAM_TTY set to "tty1" then it works correctly otherwise not e.g. for "tty7" etc?

I would really appreciate if someone (or related person) responds at the earliest :-)

BR
imran
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Roman Kubiak
2014-12-15 12:00:02 UTC
Permalink
2. i can't tell
1. if you want custom smack rules you should look at udev rules on the
system in /lib/udev/rules.d or /etc/udev/rules.d
On 12/15/2014 12:18 PM, Zaman, Imran wrote:
> Hei!
>
> Recently we have encountered an issue that if a PAM user session has PAM_TTY set as "tty1", then it sets appropriate smack labels for /dev/snd/*.
> otherwise the smack labels are not set appropriately for any other value and the devices become inaccessible.
>
> Can someone please indicate,
> a- Which component is responsible for setting up the smack lables for /dev/snd/* on the fly? Is it systemd?
> b- Why is it hard-coded such that if PAM session has PAM_TTY set to "tty1" then it works correctly otherwise not e.g. for "tty7" etc?
>
> I would really appreciate if someone (or related person) responds at the earliest :-)
>
> BR
> imran
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> Dev mailing list
> ***@lists.tizen.org
> https://lists.tizen.org/listinfo/dev
>

--
--------------
Roman Kubiak
--------------
Schaufler, Casey
2014-12-15 16:58:30 UTC
Permalink
> -----Original Message-----
> From: Dev [mailto:dev-***@lists.tizen.org] On Behalf Of Zaman, Imran
> Sent: Monday, December 15, 2014 3:18 AM
> To: ***@lists.tizen.org
> Cc: Laako, Jussi
> Subject: [Dev] SMACK Labels for /dev/snd/*
> Importance: High
>
> Hei!
>
> Recently we have encountered an issue that if a PAM user session has
> PAM_TTY set as "tty1", then it sets appropriate smack labels for /dev/snd/*.

What label do the files get?

> otherwise the smack labels are not set appropriately for any other value and
> the devices become inaccessible.

What label do they get? What would you like it to be?

>
> Can someone please indicate,
> a- Which component is responsible for setting up the smack lables for
> /dev/snd/* on the fly? Is it systemd?
> b- Why is it hard-coded such that if PAM session has PAM_TTY set to "tty1"
> then it works correctly otherwise not e.g. for "tty7" etc?

/lib/udev/rules.d is the repository for device labeling rules.

> I would really appreciate if someone (or related person) responds at the
> earliest :-)

Wouldn't we all? :)

> BR
> imran
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> Dev mailing list
> ***@lists.tizen.org
> https://lists.tizen.org/listinfo/dev
Whiteman, John L
2014-12-16 00:44:01 UTC
Permalink
I checked on the pam side as well. You may want to look at
upstream/pam/modules/pam_access configuration files. Valid names should be
in ttyname() form only. Modules pam_securetty and pam_smack only take a
valid pam name as a string. Nothing hard-coded. It would be an interesting
experiment if you explicitly allow tty1 ... tty# in
/etc/security/access.conf to see if that works on your system. There you
can run strace to see where it gets set.

-----Original Message-----
From: Dev [mailto:dev-***@lists.tizen.org] On Behalf Of Schaufler, Casey
Sent: Monday, December 15, 2014 8:59 AM
To: Zaman, Imran; ***@lists.tizen.org
Cc: Laako, Jussi
Subject: Re: [Dev] SMACK Labels for /dev/snd/*

> -----Original Message-----
> From: Dev [mailto:dev-***@lists.tizen.org] On Behalf Of Zaman,
> Imran
> Sent: Monday, December 15, 2014 3:18 AM
> To: ***@lists.tizen.org
> Cc: Laako, Jussi
> Subject: [Dev] SMACK Labels for /dev/snd/*
> Importance: High
>
> Hei!
>
> Recently we have encountered an issue that if a PAM user session has
> PAM_TTY set as "tty1", then it sets appropriate smack labels for
/dev/snd/*.

What label do the files get?

> otherwise the smack labels are not set appropriately for any other
> value and the devices become inaccessible.

What label do they get? What would you like it to be?

>
> Can someone please indicate,
> a- Which component is responsible for setting up the smack lables for
> /dev/snd/* on the fly? Is it systemd?
> b- Why is it hard-coded such that if PAM session has PAM_TTY set to "tty1"
> then it works correctly otherwise not e.g. for "tty7" etc?

/lib/udev/rules.d is the repository for device labeling rules.

> I would really appreciate if someone (or related person) responds at
> the earliest :-)

Wouldn't we all? :)

> BR
> imran
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki Business Identity Code:
> 0357606 - 4 Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> Dev mailing list
> ***@lists.tizen.org
> https://lists.tizen.org/listinfo/dev
Schaufler, Casey
2014-12-16 03:09:41 UTC
Permalink
> -----Original Message-----
> From: Whiteman, John L
> Sent: Monday, December 15, 2014 4:44 PM
> To: Schaufler, Casey; Zaman, Imran; ***@lists.tizen.org
> Cc: Laako, Jussi
> Subject: RE: SMACK Labels for /dev/snd/*
>
> I checked on the pam side as well. You may want to look at
> upstream/pam/modules/pam_access configuration files. Valid names
> should be
> in ttyname() form only. Modules pam_securetty and pam_smack only take a
> valid pam name as a string. Nothing hard-coded. It would be an
interesting
> experiment if you explicitly allow tty1 ... tty# in
> /etc/security/access.conf to see if that works on your system. There you
> can run strace to see where it gets set.


This could be another manifestation of TC-1755. I am testing a fix for that
now.


> -----Original Message-----
> From: Dev [mailto:dev-***@lists.tizen.org] On Behalf Of Schaufler,
> Casey
> Sent: Monday, December 15, 2014 8:59 AM
> To: Zaman, Imran; ***@lists.tizen.org
> Cc: Laako, Jussi
> Subject: Re: [Dev] SMACK Labels for /dev/snd/*
>
> > -----Original Message-----
> > From: Dev [mailto:dev-***@lists.tizen.org] On Behalf Of Zaman,
> > Imran
> > Sent: Monday, December 15, 2014 3:18 AM
> > To: ***@lists.tizen.org
> > Cc: Laako, Jussi
> > Subject: [Dev] SMACK Labels for /dev/snd/*
> > Importance: High
> >
> > Hei!
> >
> > Recently we have encountered an issue that if a PAM user session has
> > PAM_TTY set as "tty1", then it sets appropriate smack labels for
> /dev/snd/*.
>
> What label do the files get?
>
> > otherwise the smack labels are not set appropriately for any other
> > value and the devices become inaccessible.
>
> What label do they get? What would you like it to be?
>
> >
> > Can someone please indicate,
> > a- Which component is responsible for setting up the smack lables for
> > /dev/snd/* on the fly? Is it systemd?
> > b- Why is it hard-coded such that if PAM session has PAM_TTY set to
"tty1"
> > then it works correctly otherwise not e.g. for "tty7" etc?
>
> /lib/udev/rules.d is the repository for device labeling rules.
>
> > I would really appreciate if someone (or related person) responds at
> > the earliest :-)
>
> Wouldn't we all? :)
>
> > BR
> > imran
> > ---------------------------------------------------------------------
> > Intel Finland Oy
> > Registered Address: PL 281, 00181 Helsinki Business Identity Code:
> > 0357606 - 4 Domiciled in Helsinki
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
> > _______________________________________________
> > Dev mailing list
> > ***@lists.tizen.org
> > https://lists.tizen.org/listinfo/dev
> _______________________________________________
> Dev mailing list
> ***@lists.tizen.org
> https://lists.tizen.org/listinfo/dev
Zaman, Imran
2014-12-16 12:56:52 UTC
Permalink
Hi

> Recently we have encountered an issue that if a PAM user session has
> PAM_TTY set as "tty1", then it sets appropriate smack labels for
/dev/snd/*.

What label do the files get?

> otherwise the smack labels are not set appropriately for any other
> value and the devices become inaccessible.

What label do they get? What would you like it to be?

When tty1 is used as PAM_TTY for use session then file access are as below and works.. NOTE crw-rw----+
***@ivi_box:~# ls -lZa /dev/snd/*
crw-rw----+ 1 root audio * 116, 0 Dec 15 15:38 /dev/snd/controlC0
crw-rw----+ 1 root audio * 116, 32 Dec 15 15:38 /dev/snd/controlC1
crw-rw----+ 1 root audio * 116, 4 Dec 15 15:38 /dev/snd/hwC0D0
crw-rw----+ 1 root audio * 116, 6 Dec 15 15:38 /dev/snd/hwC0D2
crw-rw----+ 1 root audio * 116, 24 Dec 15 07:43 /dev/snd/pcmC0D0c
crw-rw----+ 1 root audio * 116, 16 Dec 15 07:43 /dev/snd/pcmC0D0p
crw-rw----+ 1 root audio * 116, 26 Dec 15 15:38 /dev/snd/pcmC0D2c
crw-rw----+ 1 root audio * 116, 19 Dec 15 07:43 /dev/snd/pcmC0D3p
crw-rw----+ 1 root audio * 116, 23 Dec 15 07:43 /dev/snd/pcmC0D7p
crw-rw----+ 1 root audio * 116, 56 Dec 15 07:43 /dev/snd/pcmC1D0c
crw-rw----+ 1 root audio * 116, 48 Dec 15 07:43 /dev/snd/pcmC1D0p
crw-rw----+ 1 root audio * 116, 1 Dec 15 15:38 /dev/snd/seq
crw-rw----+ 1 root audio * 116, 33 Dec 15 15:38 /dev/snd/timer

When tty1 is NOT used as PAM_TTY for use session then file access are as below and DOESNT works.. NOTE crw-rw----.
***@ivi_box:~# ls -lZa /dev/snd/*
crw-rw----. 1 root audio * 116, 0 Dec 16 2014 /dev/snd/controlC0
crw-rw----. 1 root audio * 116, 32 Dec 16 2014 /dev/snd/controlC1
crw-rw----. 1 root audio * 116, 4 Dec 16 2014 /dev/snd/hwC0D0
crw-rw----. 1 root audio * 116, 6 Dec 16 2014 /dev/snd/hwC0D2
crw-rw----. 1 root audio * 116, 24 Dec 16 2014 /dev/snd/pcmC0D0c
crw-rw----. 1 root audio * 116, 16 Dec 16 2014 /dev/snd/pcmC0D0p
crw-rw----. 1 root audio * 116, 26 Dec 16 2014 /dev/snd/pcmC0D2c
crw-rw----. 1 root audio * 116, 19 Dec 16 2014 /dev/snd/pcmC0D3p
crw-rw----. 1 root audio * 116, 23 Dec 16 2014 /dev/snd/pcmC0D7p
crw-rw----. 1 root audio * 116, 56 Dec 16 2014 /dev/snd/pcmC1D0c
crw-rw----. 1 root audio * 116, 48 Dec 16 2014 /dev/snd/pcmC1D0p
crw-rw----. 1 root audio * 116, 1 Dec 16 2014 /dev/snd/seq
crw-rw----. 1 root audio * 116, 33 Dec 16 2014 /dev/snd/timer

BR
imran

----------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki Business Identity Code:
> 0357606 - 4 Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> Dev mailing list
> ***@lists.tizen.org
> https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
***@lists.tizen.org
https://lists.tizen.org/listinfo/dev
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
José Bollo
2014-12-16 13:04:49 UTC
Permalink
Le mardi 16 décembre 2014 à 12:56 +0000, Zaman, Imran a écrit :
> Hi
>
> > Recently we have encountered an issue that if a PAM user session has
> > PAM_TTY set as "tty1", then it sets appropriate smack labels for
> /dev/snd/*.
>
> What label do the files get?
>
> > otherwise the smack labels are not set appropriately for any other
> > value and the devices become inaccessible.
>
> What label do they get? What would you like it to be?
>
> When tty1 is used as PAM_TTY for use session then file access are as below and works.. NOTE crw-rw----+
> ***@ivi_box:~# ls -lZa /dev/snd/*
> crw-rw----+ 1 root audio * 116, 0 Dec 15 15:38 /dev/snd/controlC0
> crw-rw----+ 1 root audio * 116, 32 Dec 15 15:38 /dev/snd/controlC1
> crw-rw----+ 1 root audio * 116, 4 Dec 15 15:38 /dev/snd/hwC0D0
> crw-rw----+ 1 root audio * 116, 6 Dec 15 15:38 /dev/snd/hwC0D2
> crw-rw----+ 1 root audio * 116, 24 Dec 15 07:43 /dev/snd/pcmC0D0c
> crw-rw----+ 1 root audio * 116, 16 Dec 15 07:43 /dev/snd/pcmC0D0p
> crw-rw----+ 1 root audio * 116, 26 Dec 15 15:38 /dev/snd/pcmC0D2c
> crw-rw----+ 1 root audio * 116, 19 Dec 15 07:43 /dev/snd/pcmC0D3p
> crw-rw----+ 1 root audio * 116, 23 Dec 15 07:43 /dev/snd/pcmC0D7p
> crw-rw----+ 1 root audio * 116, 56 Dec 15 07:43 /dev/snd/pcmC1D0c
> crw-rw----+ 1 root audio * 116, 48 Dec 15 07:43 /dev/snd/pcmC1D0p
> crw-rw----+ 1 root audio * 116, 1 Dec 15 15:38 /dev/snd/seq
> crw-rw----+ 1 root audio * 116, 33 Dec 15 15:38 /dev/snd/timer
>
> When tty1 is NOT used as PAM_TTY for use session then file access are as below and DOESNT works.. NOTE crw-rw----.
> ***@ivi_box:~# ls -lZa /dev/snd/*
> crw-rw----. 1 root audio * 116, 0 Dec 16 2014 /dev/snd/controlC0
> crw-rw----. 1 root audio * 116, 32 Dec 16 2014 /dev/snd/controlC1
> crw-rw----. 1 root audio * 116, 4 Dec 16 2014 /dev/snd/hwC0D0
> crw-rw----. 1 root audio * 116, 6 Dec 16 2014 /dev/snd/hwC0D2
> crw-rw----. 1 root audio * 116, 24 Dec 16 2014 /dev/snd/pcmC0D0c
> crw-rw----. 1 root audio * 116, 16 Dec 16 2014 /dev/snd/pcmC0D0p
> crw-rw----. 1 root audio * 116, 26 Dec 16 2014 /dev/snd/pcmC0D2c
> crw-rw----. 1 root audio * 116, 19 Dec 16 2014 /dev/snd/pcmC0D3p
> crw-rw----. 1 root audio * 116, 23 Dec 16 2014 /dev/snd/pcmC0D7p
> crw-rw----. 1 root audio * 116, 56 Dec 16 2014 /dev/snd/pcmC1D0c
> crw-rw----. 1 root audio * 116, 48 Dec 16 2014 /dev/snd/pcmC1D0p
> crw-rw----. 1 root audio * 116, 1 Dec 16 2014 /dev/snd/seq
> crw-rw----. 1 root audio * 116, 33 Dec 16 2014 /dev/snd/timer


Nice catch!

IMHO the group have to be checked.
BR
José

> BR
> imran
>
> ----------------------------------------------------------------
> > Intel Finland Oy
> > Registered Address: PL 281, 00181 Helsinki Business Identity Code:
> > 0357606 - 4 Domiciled in Helsinki
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
> > _______________________________________________
> > Dev mailing list
> > ***@lists.tizen.org
> > https://lists.tizen.org/listinfo/dev
> _______________________________________________
> Dev mailing list
> ***@lists.tizen.org
> https://lists.tizen.org/listinfo/dev
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> Dev mailing list
> ***@lists.tizen.org
> https://lists.tizen.org/listinfo/dev
Jussi Laako
2014-12-16 13:12:41 UTC
Permalink
On 16.12.2014 14:56, Zaman, Imran wrote:
> When tty1 is NOT used as PAM_TTY for use session then file access are as below and DOESNT works.. NOTE crw-rw----.

Just as a clarification, regardless if PAM_TTY is set for example to
"tty2", or just not set at all, things don't work. So it must be set
exactly to "tty1" for things to work...

We were originally using "tty7" which is the first free one and were
wondering for long time what is the culprit.

After lengthy comparison with user-session-launch source code we noticed
that it has PAM_TTY=tty1 hardcoded and finally we tried that in tlm.conf
and things started to work... This detail certainly wasn't our primary
suspect...
Schaufler, Casey
2014-12-16 14:53:15 UTC
Permalink
> -----Original Message-----
> From: Zaman, Imran
> Sent: Tuesday, December 16, 2014 4:57 AM
> To: Whiteman, John L; Schaufler, Casey; ***@lists.tizen.org
> Cc: Laako, Jussi
> Subject: RE: SMACK Labels for /dev/snd/*
>
> Hi
>
> > Recently we have encountered an issue that if a PAM user session has
> > PAM_TTY set as "tty1", then it sets appropriate smack labels for
> /dev/snd/*.
>
> What label do the files get?
>
> > otherwise the smack labels are not set appropriately for any other
> > value and the devices become inaccessible.
>
> What label do they get? What would you like it to be?
>
> When tty1 is used as PAM_TTY for use session then file access are as below
> and works.. NOTE crw-rw----+

The "+" indicates there is an ACL on the file. The "*" is the Smack label.
Everyone always has access to files with the "*" label.

> ***@ivi_box:~# ls -lZa /dev/snd/*
> crw-rw----+ 1 root audio * 116, 0 Dec 15 15:38 /dev/snd/controlC0
> crw-rw----+ 1 root audio * 116, 32 Dec 15 15:38 /dev/snd/controlC1
> crw-rw----+ 1 root audio * 116, 4 Dec 15 15:38 /dev/snd/hwC0D0
> crw-rw----+ 1 root audio * 116, 6 Dec 15 15:38 /dev/snd/hwC0D2
> crw-rw----+ 1 root audio * 116, 24 Dec 15 07:43 /dev/snd/pcmC0D0c
> crw-rw----+ 1 root audio * 116, 16 Dec 15 07:43 /dev/snd/pcmC0D0p
> crw-rw----+ 1 root audio * 116, 26 Dec 15 15:38 /dev/snd/pcmC0D2c
> crw-rw----+ 1 root audio * 116, 19 Dec 15 07:43 /dev/snd/pcmC0D3p
> crw-rw----+ 1 root audio * 116, 23 Dec 15 07:43 /dev/snd/pcmC0D7p
> crw-rw----+ 1 root audio * 116, 56 Dec 15 07:43 /dev/snd/pcmC1D0c
> crw-rw----+ 1 root audio * 116, 48 Dec 15 07:43 /dev/snd/pcmC1D0p
> crw-rw----+ 1 root audio * 116, 1 Dec 15 15:38 /dev/snd/seq
> crw-rw----+ 1 root audio * 116, 33 Dec 15 15:38 /dev/snd/timer
>
> When tty1 is NOT used as PAM_TTY for use session then file access are as
> below and DOESNT works.. NOTE crw-rw----.

You still have the "*" Smack label. Smack isn't the problem.

Hypotheses: The ACL on the files above explicitly allows access
for the logged in user. Look at the ACL.

> ***@ivi_box:~# ls -lZa /dev/snd/*
> crw-rw----. 1 root audio * 116, 0 Dec 16 2014 /dev/snd/controlC0
> crw-rw----. 1 root audio * 116, 32 Dec 16 2014 /dev/snd/controlC1
> crw-rw----. 1 root audio * 116, 4 Dec 16 2014 /dev/snd/hwC0D0
> crw-rw----. 1 root audio * 116, 6 Dec 16 2014 /dev/snd/hwC0D2
> crw-rw----. 1 root audio * 116, 24 Dec 16 2014 /dev/snd/pcmC0D0c
> crw-rw----. 1 root audio * 116, 16 Dec 16 2014 /dev/snd/pcmC0D0p
> crw-rw----. 1 root audio * 116, 26 Dec 16 2014 /dev/snd/pcmC0D2c
> crw-rw----. 1 root audio * 116, 19 Dec 16 2014 /dev/snd/pcmC0D3p
> crw-rw----. 1 root audio * 116, 23 Dec 16 2014 /dev/snd/pcmC0D7p
> crw-rw----. 1 root audio * 116, 56 Dec 16 2014 /dev/snd/pcmC1D0c
> crw-rw----. 1 root audio * 116, 48 Dec 16 2014 /dev/snd/pcmC1D0p
> crw-rw----. 1 root audio * 116, 1 Dec 16 2014 /dev/snd/seq
> crw-rw----. 1 root audio * 116, 33 Dec 16 2014 /dev/snd/timer
>
> BR
> imran
>
> ----------------------------------------------------------------
> > Intel Finland Oy
> > Registered Address: PL 281, 00181 Helsinki Business Identity Code:
> > 0357606 - 4 Domiciled in Helsinki
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
> > _______________________________________________
> > Dev mailing list
> > ***@lists.tizen.org
> > https://lists.tizen.org/listinfo/dev
> _______________________________________________
> Dev mailing list
> ***@lists.tizen.org
> https://lists.tizen.org/listinfo/dev
Zaman, Imran
2014-12-16 15:10:44 UTC
Permalink
_
> When tty1 is NOT used as PAM_TTY for use session then file access are as
> below and DOESNT works.. NOTE crw-rw----.

You still have the "*" Smack label. Smack isn't the problem.

Hypotheses: The ACL on the files above explicitly allows access
for the logged in user. Look at the ACL.

Thanks.. Can you please point where shall I look at ACL? i.e. which package/repo/configuration..

BR
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Thiago Macieira
2014-12-16 16:34:53 UTC
Permalink
On Tuesday 16 December 2014 15:10:44 Zaman, Imran wrote:
> _
>
> > When tty1 is NOT used as PAM_TTY for use session then file access are as
> > below and DOESNT works.. NOTE crw-rw----.
>
> You still have the "*" Smack label. Smack isn't the problem.
>
> Hypotheses: The ACL on the files above explicitly allows access
> for the logged in user. Look at the ACL.
>
> Thanks.. Can you please point where shall I look at ACL? i.e. which
> package/repo/configuration..

chacl -l /dev/snd/controlC0

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Kaskinen, Tanu
2014-12-17 09:15:32 UTC
Permalink
On Tue, 2014-12-16 at 15:10 +0000, Zaman, Imran wrote:
> _
> > When tty1 is NOT used as PAM_TTY for use session then file access are as
> > below and DOESNT works.. NOTE crw-rw----.
>
> You still have the "*" Smack label. Smack isn't the problem.
>
> Hypotheses: The ACL on the files above explicitly allows access
> for the logged in user. Look at the ACL.
>
> Thanks.. Can you please point where shall I look at ACL? i.e. which package/repo/configuration..

(Could you please fix your quoting? There's no indication what you have
quoted and what is your own text.)

If you're looking for the place where those ACLs are set, that would be
logind's source code. The logic that logind implements is that if a
device has been assigned to a seat, then logind gives access to the user
that currently has an active session on that seat. If you see
"crw-rw----.", my guess is that in logind's opinion nobody has an active
session on the seat.

--
Tanu
Jussi Laako
2014-12-17 13:25:48 UTC
Permalink
On 17.12.2014 11:15, Kaskinen, Tanu wrote:
> If you're looking for the place where those ACLs are set, that would be
> logind's source code. The logic that logind implements is that if a
> device has been assigned to a seat, then logind gives access to the user
> that currently has an active session on that seat. If you see
> "crw-rw----.", my guess is that in logind's opinion nobody has an active
> session on the seat.

But why does the session have to be specifically on "tty1". If it's
"tty2", then the permissions are incorrect. Based on "loginctl" the
session is on "seat0" in both cases (and the devices are attached to
seat0)...
Kaskinen, Tanu
2014-12-17 14:18:17 UTC
Permalink
On Wed, 2014-12-17 at 15:25 +0200, Jussi Laako wrote:
> On 17.12.2014 11:15, Kaskinen, Tanu wrote:
> > If you're looking for the place where those ACLs are set, that would be
> > logind's source code. The logic that logind implements is that if a
> > device has been assigned to a seat, then logind gives access to the user
> > that currently has an active session on that seat. If you see
> > "crw-rw----.", my guess is that in logind's opinion nobody has an active
> > session on the seat.
>
> But why does the session have to be specifically on "tty1". If it's
> "tty2", then the permissions are incorrect. Based on "loginctl" the
> session is on "seat0" in both cases (and the devices are attached to
> seat0)...

My theory is that logind for some reason thinks that tty1 is active no
matter what you do. If you set PAM_TTY to "tty2", does "loginctl
show-session" say "Active=yes" or "Active=no"?

I'm not very familiar with the tty concept, and I don't know what the
PAM_TTY variable is supposed to mean exactly... My assumptions: the VT
number corresponds to the function key number when I switch terminals
with Ctrl-Alt-F<N>. The tty number is related to the VT number, but they
are not exactly the same thing. Maybe ttys are only assigned to text
logins, while the VT can also be graphical? That theory is supported by
the fact that pam_sm_open_session() in src/login/pam_systemd.c sets the
tty variable to NULL in case of X11, cron and ssh logins before passing
it to logind. If the tty number is relevant only in the context of text
logins, and you're dealing with graphical logins, maybe the right thing
would be to unset PAM_TTY or set it to an empty string?

--
Tanu
Jussi Laako
2014-12-17 15:25:48 UTC
Permalink
On 17.12.2014 16:18, Kaskinen, Tanu wrote:
> If you set PAM_TTY to "tty2", does "loginctl
> show-session" say "Active=yes" or "Active=no"?

Yes, that's the case, but WHY!?

> PAM_TTY variable is supposed to mean exactly... My assumptions: the VT
> number corresponds to the function key number when I switch terminals
> with Ctrl-Alt-F<N>. The tty number is related to the VT number, but they
> are not exactly the same thing. Maybe ttys are only assigned to text

Yes, that's the case, we open and initialize the given /dev/ttyX, when
asked in the tlm.conf

> the fact that pam_sm_open_session() in src/login/pam_systemd.c sets the
> tty variable to NULL in case of X11, cron and ssh logins before passing
> it to logind. If the tty number is relevant only in the context of text
> logins, and you're dealing with graphical logins, maybe the right thing
> would be to unset PAM_TTY or set it to an empty string?

Initially we used tty7 for the genivi user (needed to get the weston DRM
backend up) and no TTY at all for the user compositor (wayland backend)
because TTY is not needed at all for this case. Which means that PAM_TTY
wasn't set at all. However this was the initial problem that then things
don't work. So things ONLY work when PAM_TTY=tty1 and doesn't if it's
anything else or not set.

pam_systemd is not called for the genivi user and thus logind doesn't
know about it's session at all. Thus none of the user services are
launched for it, as intended.
Jussi Laako
2014-12-17 15:39:24 UTC
Permalink
On 17.12.2014 17:25, Jussi Laako wrote:
>> the fact that pam_sm_open_session() in src/login/pam_systemd.c sets the
>> tty variable to NULL in case of X11, cron and ssh logins before passing

Overall, the problem is that systemd doesn't understand things like
having sessions under wayland/weston. It only understands about text
logins and X11 and assumes a text login when it cannot detect X11.

Then on the pam_systemd path there's a lot of undocumented mysterious
logic that changed drastically, without explanation between systemd 208
and 212 (and broke TLM already once) and is probably subject to change
in future.

Main problem of systemd is that it is making lot of strange assumptions
that are highly unlikely to hold in complex embedded configurations that
are not your usual server or desktop.
Jussi Laako
2014-12-17 15:54:31 UTC
Permalink
Here's the status when using /dev/tty1:
tty1:
Id=c1
Name=app
Timestamp=Wed 2014-12-17 13:19:54 PST
TimestampMonotonic=10146848
VTNr=1
TTY=tty1
Remote=no
RemoteHost=localhost
RemoteUser=root
Service=tlm-default-login
Scope=session-c1.scope
Leader=272
Audit=0
Type=tty
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=1418851189767108
IdleSinceHintMonotonic=28873284404


And here's the status when using /dev/tty2:
Id=c1
Name=app
Timestamp=Wed 2014-12-17 15:21:49 PST
TimestampMonotonic=10192886
VTNr=2
TTY=tty2
Remote=no
RemoteHost=localhost
RemoteUser=root
Service=tlm-default-login
Scope=session-c1.scope
Leader=270
Audit=0
Type=tty
Class=user
Active=no
State=online
IdleHint=no
IdleSinceHint=1418858504716107
IdleSinceHintMonotonic=28871766267


And here without any VT, note that state is exactly same as with tty1,
but still permissions are incorrect:
Id=c1
Name=app
Timestamp=Wed 2014-12-17 15:53:16 PST
TimestampMonotonic=11403656
VTNr=0
Remote=no
RemoteHost=localhost
RemoteUser=root
Service=tlm-default-login
Scope=session-c1.scope
Leader=271
Audit=0
Type=unspecified
Class=background
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
Kaskinen, Tanu
2014-12-17 18:05:58 UTC
Permalink
On Wed, 2014-12-17 at 17:54 +0200, Jussi Laako wrote:
> Here's the status when using /dev/tty1:
> tty1:
> Id=c1
> Name=app
> Timestamp=Wed 2014-12-17 13:19:54 PST
> TimestampMonotonic=10146848
> VTNr=1

Note: VTNr=1

> And here without any VT, note that state is exactly same as with tty1,
> but still permissions are incorrect:
> Id=c1
> Name=app
> Timestamp=Wed 2014-12-17 15:53:16 PST
> TimestampMonotonic=11403656
> VTNr=0

Note: VTNr=0

Could VTNr=0 be a problem? On my Fedora laptop my graphical session
doesn't have TTY set, but VTNr is set to 1.

--
Tanu
Jussi Laako
2014-12-18 09:40:31 UTC
Permalink
On 17.12.2014 20:05, Kaskinen, Tanu wrote:
> Could VTNr=0 be a problem? On my Fedora laptop my graphical session
> doesn't have TTY set, but VTNr is set to 1.

Well, if it is VTNr=2 it doesn't work either. VTNR is equal to
corresponding tty. Why is /dev/tty1 special here?

VTNR=1 == /dev/tty1
VTNR=2 == /dev/tty2

http://www.tldp.org/HOWTO/Text-Terminal-HOWTO-7.html#ss7.5


For example weston-launch requires that there's VT open, that's why we
open first free/unused VT (/dev/tty7) for genivi user, otherwise Weston
cannot start. This is the same that happens if you run "startx" from
normal Linux text login, it'll find first free VT and attach there. But
for user sessions that run on top of the system compositor, technically
there's no need to have any VT because they share the parent (genivi)
VT. And genivi session is not a normal user session and thus logind
doesn't know anything about it, otherwise it would attempt to launch all
systemd user services for it, such as crosswalk which is precisely what
we don't want. Similar to ssh sessions in current setup.

Or then someone would need to teach systemd/logind about different user
session types, that for session type X service set A is started and for
session type Z service B is started. Instead of blindly triggering
systemd --user and launching all user services for all logins regardless
of session type...

It should behave like we would be running under X, but it cannot detect
X because we use wayland instead.
Kaskinen, Tanu
2014-12-18 10:29:39 UTC
Permalink
On Thu, 2014-12-18 at 11:40 +0200, Jussi Laako wrote:
> On 17.12.2014 20:05, Kaskinen, Tanu wrote:
> > Could VTNr=0 be a problem? On my Fedora laptop my graphical session
> > doesn't have TTY set, but VTNr is set to 1.
>
> Well, if it is VTNr=2 it doesn't work either. VTNR is equal to
> corresponding tty. Why is /dev/tty1 special here?

I don't know. Someone on systemd-devel might know. If logind is showing
the session as active, but ACLs don't get set properly, that sounds like
a bug in logind.

> For example weston-launch requires that there's VT open, that's why we
> open first free/unused VT (/dev/tty7) for genivi user, otherwise Weston
> cannot start. This is the same that happens if you run "startx" from
> normal Linux text login, it'll find first free VT and attach there. But
> for user sessions that run on top of the system compositor, technically
> there's no need to have any VT because they share the parent (genivi)
> VT. And genivi session is not a normal user session and thus logind
> doesn't know anything about it, otherwise it would attempt to launch all
> systemd user services for it, such as crosswalk which is precisely what
> we don't want. Similar to ssh sessions in current setup.
>
> Or then someone would need to teach systemd/logind about different user
> session types, that for session type X service set A is started and for
> session type Z service B is started. Instead of blindly triggering
> systemd --user and launching all user services for all logins regardless
> of session type...

Here's one idea: assuming that you control how systemd --user is
started, you could start systemd --user for the genivi user too, but
instead of using default.target that pulls all kinds of stuff you don't
want to run for the genivi user, you could specify a different target
using the --unit option of systemd.

I don't see how this would help with the ACL problems, though. I'm just
mentioning this as an alternative solution to the problem that the
genivi user shouldn't run the normal user services.

--
Tanu
Imran Zaman
2014-12-17 15:47:45 UTC
Permalink
> I'm not very familiar with the tty concept, and I don't know what the
> PAM_TTY variable is supposed to mean exactly... My assumptions: the VT
> number corresponds to the function key number when I switch terminals
> with Ctrl-Alt-F<N>. The tty number is related to the VT number, but they
> are not exactly the same thing. Maybe ttys are only assigned to text
> logins, while the VT can also be graphical? That theory is supported by
> the fact that pam_sm_open_session() in src/login/pam_systemd.c sets the
> tty variable to NULL in case of X11, cron and ssh logins before passing
> it to logind. If the tty number is relevant only in the context of text
> logins, and you're dealing with graphical logins, maybe the right thing
> would be to unset PAM_TTY or set it to an empty string?
>

Just tested PAM_TTY="" and Active=yes can be seen below. But the real
problem is that /dev/snd/* is still following normal ACL as you can for
the access rights for /dev/snd/* below, which is what we are wondering
that which component is actually setting the ACL when PAM_TTY=tty1?

***@ivi_box:~# loginctl show-session c1
Id=c1
Name=app
Timestamp=Wed 2014-12-17 15:40:17 PST
TimestampMonotonic=9853533
VTNr=2
Remote=no
RemoteHost=localhost
RemoteUser=root
Service=tlm-default-login
Scope=session-c1.scope
Leader=275
Audit=0
Type=unspecified
Class=background
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0

***@ivi_box:~# ls -lZa /dev/snd/*
crw-rw----. 1 root audio * 116, 0 Dec 17 2014 /dev/snd/controlC0
crw-rw----. 1 root audio * 116, 32 Dec 17 2014 /dev/snd/controlC1
crw-rw----. 1 root audio * 116, 4 Dec 17 2014 /dev/snd/hwC0D0
Kaskinen, Tanu
2014-12-17 20:07:31 UTC
Permalink
On Wed, 2014-12-17 at 17:47 +0200, Imran Zaman wrote:
>
> > I'm not very familiar with the tty concept, and I don't know what the
> > PAM_TTY variable is supposed to mean exactly... My assumptions: the VT
> > number corresponds to the function key number when I switch terminals
> > with Ctrl-Alt-F<N>. The tty number is related to the VT number, but they
> > are not exactly the same thing. Maybe ttys are only assigned to text
> > logins, while the VT can also be graphical? That theory is supported by
> > the fact that pam_sm_open_session() in src/login/pam_systemd.c sets the
> > tty variable to NULL in case of X11, cron and ssh logins before passing
> > it to logind. If the tty number is relevant only in the context of text
> > logins, and you're dealing with graphical logins, maybe the right thing
> > would be to unset PAM_TTY or set it to an empty string?
> >
>
> Just tested PAM_TTY="" and Active=yes can be seen below. But the real
> problem is that /dev/snd/* is still following normal ACL as you can for
> the access rights for /dev/snd/* below, which is what we are wondering
> that which component is actually setting the ACL when PAM_TTY=tty1?

I'm sure it's logind. Based on the file name, I'd guess
src/login/logind-acl.c would be a good place to start looking.

--
Tanu
Continue reading on narkive:
Loading...