On Mon, 30 Nov 1998, Dr. Robert J. Meier wrote:
> Anders,
>
> > I'd like the user currently logged in on the console to own the console. how
> > do I configure that? What are the `correct` mask to use?
>
> Normally, the raw devices like /dev/console are owned by root. This
> makes it difficult to accidently corrupt them. Further restrictions are
> usually applied by symbolic link. Ownership is authority to
> grant or deny access. Why do you want the currently logged in user to have
> authority to grant or deny access to the command line channel used by the
> kernel? What do you want to do that you can't do with the usual console mode,
> crw--w-w- root sys?
You want to deny or allow access to other users logged in, s.t. incoming
talk's and write's don't corrupt your input. That is, you want to change
read/write permissions on the device, that is, you must own it.
Admitted, a bad side effect is that you can screw up your termios setting,
maybe logging yourself out of the system. Looked at it from this
perspective, it would be better to implement the mesg -y / -n command in
another fashion and make talkd, write, etc. suid root and honour the mesg
settings stored elsewhere. Now suid root bins have other problems on there
own too.
Another point is that a user logged in at the system console might want to
redirect console output to an xterm window, again this requires access to
/dev/console (yet again, normally xterm/xconsole/etc are suid root for
this reason).
> If you want to further restrict the abilities of the current logged in
> user, you need only make a symbolic link to /dev/console and deny the abilities
> you wish. (e.g. ln -s /dev/console /dev/loggedinuser; chmod o-w
> /dev/loggedinuser).
Alas, you can't set any permissions on a symbolic link (and if you can,
they don't have an effect). You could create another device node (mknod)
with the same device numbers, but then you could simply change permissions
on the first device node.
> If you want to grant the logged in user ability to set the speed and
> special characters for /dev/console, then as root grant read permission.
I'm unsure if read permission is what you need. Actually, the console will
be your stdin/out, hence opened already for you. You don't need any
permission to open the device then anymore (for this).
> (e.g. sudo chmod a+r /dev/console) Be careful lest the logged in user
> render the console inaccessible (until the system is rebooted).
If he logs out, however, getty will regain control and a sensible getty
will reset the console device.
> Since /dev/console is mounted at sytem initialization before X is run
/dev/console bears no filesystem and is hence not mounted. You're right,
however, that the uid of the user logging in later is not known at that
point.
> and anybody logs in, it cannot be initially owned by the logged in user. It
> can not be owned by an as yet unknown user. A script would have to be run as
> part of the login to change ownership of /dev/console from root. I am
And yet again, a sensible getty/login combo does exactly this upon login.
Note, however, that not the ownership of /dev/console is modified, but of
the tty or virtual console where the user logs in. Changing /dev/console
makes no sense, as several users might be logged in. Probably you think
/dev/console should bear ownership of the owner of the console currently
active. Now, only the kernel could know this, but it has no direct control
over the filesystem where /dev/console reside. Only a virtual /dev
filesystem could do that. But then, you'd only need that for redirecting
kernel errors, almost all programs to do that are suid root already
anyway.
> unfamiliar with the mechanism for enforcing system-wide login procedures, but
> believe that there is a file (/usr/X11/lib/system.login?) that can contain
> such procedures.
>
> Confused,
> --
> Robert Meier
>
> FANUC Robotics North America, Inc. [EMAIL PROTECTED]
> Voice: 1-248-377-7469 Fax: 1-248-377-7363
>
--
Michael Weller: [EMAIL PROTECTED], [EMAIL PROTECTED],
or even [EMAIL PROTECTED] If you encounter an eowmob account on
any machine in the net, it's very likely it's me.
