kmscon and /etc/securetty

[larsks]

Because kmscon dynamically allocates pty devices it makes /etc/securetty useless as an access control mechanism. Being able to make access decisions based on "someone is on a local console" is a useful feature, so it would be nice if there were some way to expose this information to PAM in the kmscon environment.

[dvdhrm]

PAM stuff is currently handled by /bin/login. So if you want to tell /bin/login that this is a local login, you need to extend /bin/login.

If there is support in PAM or /bin/login to do that, I will add the required functionality to kmscon. However, until then, I cannot change kmscon to do that.

Could you report that to upstream util-linux or PAM bugtrackers?

Regards David

[larsks]

you need to extend /bin/login.

...and really anything else that expects to use securetty. I don't have a solution in mind, I just figured it was worth thinking about.

[yuyichao]

Maybe some what related, the access to audio devices etc. provided by logind's pam using acl doesn't work either.

[dvdhrm]

@yuyichao You mean you cannot use audio devices from the command-line inside of kmscon? Could you tell me exactly what you mean because that should all work inside of kmscon.

[yuyichao]

@dvdhrm Yes. So since a recent version of systemd, being in the audio group is not required anymore in order to use audio device in a local session. Instead, systemd's pam module will use ACL to provide audio device access if it is a local session. You can see this from the output of getfacl /dev/snd/* and below is part of the output here:

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
user:yuyichao:rw-
group::rw-
mask::rw-
other::---

I'm not really familiar with either pam or ACL but I think the pam module of systemd which is loaded by login decide whether this is a local session from the name of the tty since this works with getty perfectly.

(P.S. I haven't tried to modify /etc/security because that doesn't seem to be the right permanent solution...)

[yuyichao]

Another really minor problem that is also related to the "wrong" tty name is that the login prompt shown by login is also different......

[dvdhrm]

@yuyichao The login prompt is only different because agetty implements it's own prompt (but only for the first login attempt).

Regarding ACLs: They are set up by systemd-logind and not by the pam module. They should work properly because the pam session is correctly authenticated. Could you check whether "loginctl" shows your kmscon session as "active"? Because inactive sessions don't get all permissions.

All in all I think this is a systemd bug. If something works with the xserver or weston, it should also work with kmscon. I currently cannot understand what is going wrong here.

[yuyichao]

@dvdhrm THX. I will try more later today. P.S. I activate kmscon by replacng the autotty target in /etc, not sure if that matters.

[yuyichao]

This is the output of the session status.

yuyichao% loginctl session-status 2
2 - yuyichao (1000)
           Since: 一 2013-04-15 00:37:17 EDT; 3 days ago
          Leader: 6006 (login)
            Seat: seat0
             TTY: pts/2
         Service: login; type tty; class user
           State: online
          CGroup: name=systemd:/user/yuyichao/2
                  ├─6006 login -- yuyichao
                  └─6012 -zsh

The working X11 (KDE) session looks like,

yuyichao% loginctl session-status 1
1 - yuyichao (1000)
           Since: 日 2013-04-14 17:26:03 EDT; 3 days ago
          Leader: 298 (kdm)
            Seat: seat0; vc7
         Display: :0
         Service: kde; type x11; class user
           State: active
          CGroup: name=systemd:/user/yuyichao/1
                  ├─  298 -:0

[yuyichao]

Oh, yes the session is not active.... but when I run loginctl activate 2, it fails with

Failed to issue method call: No such device or address

anywhere to see the log of logind?....