I'm working on a project to launch xterm as a user,... force it to remain on top through wmctrl, restrict access to the tty terminals, and still allow the xterm user to use sudo &/or su...

First, I didn't design the system, I'm just trying to work within it...

The machine net boots from a server, and runs processes as root (not my idea, but it has to be that way,... for now). The server can instruct the network client to run various services (as root). You can currently Alt-Ctrl-F[n] to a tty on the client, which gives you root (not real secure, I know). There is no root password assigned. Starting an xterm also gives you root (yeah,... I know). Currently, no active user accounts are set up for actual login use. This client runs as an "appliance."

What I want to do is restrict tty access, without compromising any processes that might be running as root, but allow ssh to the tty from the server. I also want to be able to launch an xterm session and allow that user to use sudo an/or su to gain root authority, if required/desired.

I figure I'll have to create a limited user account on the client, at minimum. What is the minimum in terms of environment for the user account, that I have to define to be able to run an xterm -ls on the client, and what do I need to do to add that user to the sudoers list???

It won't matter if the user can't inherit the services and environment currently running on the Xserver, (no need to cut and paste, interact that much with running programs in a desktop setting, since the xterm terminal window will be defined to act kinda like guake) as long as the user could run thing like top, sql querries, etc... I just need to keep the xterm session on top (I'll be setting transparency in xterm's config) using wmctrl and allow use of the keyboard. The user also needs to be able to use sudo and/or su to gain root authority.

Also,... What would be the best way to restrict access to the tty 's, locally, but still permit the system admin to ssh into the client from the server and have root authority?

I've got full root authority on the box (I'm actually the machines' owner),... So I can make any changes necessary. I just don't to mess with it too much as it is doing something I want to keep it doing.

If anyone has suggestions I'd appreciate them. Thanks in advance.

Maybe it's just me but by cutting out the fluff this is what remains. Feel free to correct anything:
Please first confirm it it's a PXE boot or not and if it is then what image does the client boot (be verbose)? You have to know what the client environment currently provides to be able to figure out if slash which modification are possible or not, same goes in case it's not a thin client setup.

*As for Sudo I suggest you read 'man sudo; man sudoers' first. That way you'll be able to ask specific questions.

unSpawn,...

Yes, you got it right. Yes, it is a PXE booted client. I've now learned that user accounts created on the Server are accessible through NIS (login disabled by default). I thought that operations were just being messaged to run locally by the server and some outputs were being directed to the the user account directories on the Server. That still might be right (for some things, at least).

There is a preference by those who designed the system architecture/project to use the NIS authenticated user accounts, defined at setup. But, this particular network system is my personal system. Things I change may make it back as a contribution to the system project as an add-on feature, however (and I'd like to see that, as opposed to me just making hacks on my personal system).

So, the preference might be to launch xterm on the client as the NIS authenticated user... I want to be able to make sure that all xterm window commands are being executed on the PXE booted client machine, as opposed to the server (e.g.: running top, locally, to observe running processes). I also want to make sure that the environment settings I may need to define for xterm do not interfere with anything that's already set up, and used, for something else. I'm not familiar enough with NIS, and how it works, to know where any processes are run by default... local? host?

I don't know what environment settings are in the user accounts on the server, or everything they are used for. Login for the NIS user accounts on the server is disabled by default, making me think that no (little?) environment is defined, and the accounts are just used to define/refine permissions for saved/shared files, both in the accounts and elsewhere in the system, maybe for keeping some communications stuff and as a holding bin for other settings stuff. The default disabled login configuration can be changed, according to the system architects. The majority of processes running on the client are owned by root, or by the accounts specific to those processes.

If it's safer to do it the way I intended, originally (create new "local" accounts), I may still end up going with that. Ultimately, the intent is to build a tack-on feature (an xterm window, that can be called up for admin tasks, observing processes, etc.) that can be run on the clients, and just maybe sure up local client security (a little tiny bit) in the process... It may be easier to remove it if I go with that idea,..

As for the sudo/sudoers, I can likely manage without too much help. The big thing is the user environment, and whether anything I may define interferes with what's already defined (likely; standard KDE and/or xfwm4 stuff, if anything).

Seems you have a starting point.

Well, apparently, this requires a fix to the authentication key files. The public keys were (still are) stored in /root,... and it's my understanding that the key files need proper ownership and that neither the key file, the .ssh directory, nor the folder it's in can have group or world write authorization ... am I correct? Would the keys for each user have to be in a directory owned soley by its authorized user?

Ok,...

As it turns out,... Users on the system are not create with keys to (auto)login through NIS,... So,... is there a "standard" way to do this and still try to maintain some semblance of security (I know NIS has security issues)??? And by "way,"... I mean location of the directory, the .ssh subdirectory, and the file... not an NIS front-end application for doing it... But I also mean, is there a way to keep the keyfiles relatively private, from those looking within the system (current security models deactivate external ssh access, by default).

Once I get users who can login, I can begin to create the rest without too much difficulty... I think...