Re: VT_PROCESS, VT_LOCKSWITCH capabilities

[Frank Benkstein]

Andrew Morton wrote:
> On Wed, 01 Aug 2007 04:44:32 +0200
> Frank Benkstein <frank@xxxxxxxxxxxxx> wrote:
> 
>> Frank Benkstein wrote:
>>> I wonder why there are different permissions needed for VT_PROCESS
>>> (access to the current virtual console) and VT_LOCKSWITCH
>>> (CAP_SYS_TTY_CONFIG).
>> To be more direct:
>>
>> require CAP_SYS_TTY_CONFIG for VT_SETMODE as its essentially the same as
>> VT_LOCKSWITCH and said capability is already required there
>>
>> diff --git a/drivers/char/vt_ioctl.c b/drivers/char/vt_ioctl.c
>> index c6f6f42..7034a68 100644
>> --- a/drivers/char/vt_ioctl.c
>> +++ b/drivers/char/vt_ioctl.c
>> @@ -662,7 +662,7 @@ int vt_ioctl(struct tty_struct *tty, struct file * file,
>>         {
>>                 struct vt_mode tmp;
>>
>> -               if (!perm)
>> +               if (!perm || !capable(CAP_SYS_TTY_CONFIG))
>>                         return -EPERM;
>>                 if (copy_from_user(&tmp, up, sizeof(struct vt_mode)))
>>                         return -EFAULT;
>>
> 
> There's a good risk of breaking stuff with this change.  A quick peek
> through http://www.google.com/codesearch shows that.
> 
> We need good reasons for making that change, and for handling the
> subsequent fallout, getting shouted at by aggrieved users, etc.
> 
> It's tricky.

I had a quick look through codesearch, too.  Another solution may be to
allow VT_SETMODE but deny VT_RELDISP if CAP_SYS_TTY_CONFIG is not
present. This way graphics tools still get notified when the console is
switched but can't prevent it.

It probably isn't worth the hassle.  I was just looking though the
kernel source to find out which ioctl would be better for my own console
locking tool to use.  I'm happy that it doesn't have to be setuid-root
but at the same time it nags me a little that denying service (and
potentially making users lose data because they cannot save) is so easy.
 And there is no way to switch it off.  Other than carrying the patch
myself, that is.

Regarding your earlier remark of VT_LOCKSWITCH potentially affecting the
session of the next user:  this is also possible with VT_PROCESS by
starting the locking process in the background.

-- 
GPG (Mail): 7093 7A43 CC40 463A 5564  599B 88F6 D625 BE63 866F
GPG (XMPP): 2243 DBBA F234 7C5A 6D71  3983 9F28 4D03 7110 6D51

Attachment: signature.asc
Description: OpenPGP digital signature