public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frank Benkstein <frank@benkstein.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: VT_PROCESS, VT_LOCKSWITCH capabilities
Date: Thu, 02 Aug 2007 12:31:49 +0200	[thread overview]
Message-ID: <46B1B295.1010003@benkstein.net> (raw)
In-Reply-To: <20070801151900.f80722b6.akpm@linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

Andrew Morton wrote:
> On Wed, 01 Aug 2007 04:44:32 +0200
> Frank Benkstein <frank@benkstein.net> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-08-02 10:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-31 22:22 VT_PROCESS, VT_LOCKSWITCH capabilities Frank Benkstein
2007-08-01  2:44 ` Frank Benkstein
2007-08-01 22:19   ` Andrew Morton
2007-08-02 10:31     ` Frank Benkstein [this message]
2007-08-01  4:49 ` Andrew Morton
2007-08-01  9:53   ` Frank Benkstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46B1B295.1010003@benkstein.net \
    --to=frank@benkstein.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox