User specific startup scripts

[Amanoo]

Hello. I want to run a certain script when someone logs into a specific user account. Can anyone tell me how to either have a specific user automatically run this sh script at login, or to have al members of a specific user group do this?
Note, I don't want all user accounts to run this cript. I is going to destroy nearly the whole user interface for said user, and disable him from doing anything except for using one specific piece of software, and it would be pretty nasty if this were also to happen to my administrator account.

[sea]

You could try the following

Open (create if not exists) folder /home/$thatuser/.config/autostart
Place a symlink in that directory that starts your script ( ln -s "/path/of/script/filename" "/home/$thisuser/.config/autostart/scriptname.sh")

Hope this helps

[giulix]

Or you could do like this: create a bash script in /etc/profile.d and name it, say,
chkgroup.sh

#!/bin/sh
if `echo groups` | grep -w "groupname" > /dev/null 2>&1
then
    echo "You are in the groupname group"
fi

Don't forget to make the script executable:

chmod 755 /etc/profile.d/chkgroup.sh

[Amanoo]

I tried Giulix' method. It is pretty much what I want. All I need to do now is tweak the code a bit.

[jpollard]

What you want is traditionally called a captive account, and that is harder to set up in the usual GUI accounts.

This is because nearly everything done to start users can be voided by that user once he is logged in.

The "autostart" capability can notify you when he logs in the first time, but it doesn't prevent him from doing things to the GUI that prevents it from using the autostart.

Setting up a GUI takes time, but it can be done - it is related to a kiosk mode of operation.

Some of the problems: disabling the user from selecting his own GUI at login - KDE does not initialize the same way as gnome. Both have startups, but not the same. Sometimes other window managers can be
invoked (twm the old standby, ctwm an extended twm, enlightnment, ... ). And the user can define his own startup by creating his own .xsession file that starts what he wants.

And then there is fallback mode - no default startups...

What you have to do is disable all of this to enforce such limitations.

Not easy to do, and none of xdm, gdm or kdm greeters (the login GUIs) make this easy.

Now, if all you want is just a notification, and the user doesn't mind - then it is easy do with the autostart features of KDE and Gnome.

[Amanoo]

Is it possible to run a certain script after gnome 3 has fully loaded without using a timer?

[jpollard]

The simple answer is no.

The problem is that the last program run in the script is the window manager (well usually - it acutally is whatever program used to determine when the user has logged out).

When this program terminates, the user is defined to be logged out, and the display resets for the next login.

You can actually run anything you want, but before this program starts. When this program is the manager then a significant amount of time can remain until it is in a "usable state", but you don't know when that will be.

Also remember that gnome3 is still undergoing drastic changes - the most significant hasn't occured yet (replacement of that last program by using systemd with a custom configuration). This will make it harder to do that.

[stevea]

I generally agree with jp' that attempting to assert some control of a user after login is a very dubious means of assserting control.

Instead consider using the restricted shell.

You'll need to ..
su -
<passwd>
ln -s bash /bin/rbash
echo "/bin/rbash" >> /etc/shells
system-config-users
# change the shell for each of the restricted users to /bin/rbash
^D

The consider changing each of the restricted user's PATH definition to some directory with only the few tools they need.

BTW if you really do need to compare group membership use the "id -Gn" instead of grepping through the groups file. The id command shows the active group memberships of a process, whereas grepping in /etc/groups is error prone.

[jpollard]

Unfortunately, the request was for a "restricted" GUI...

And that doesn't exist - the simple way around the restricted shell is:

xterm -e /usr/bin/bash

And because the launcher doesn't understand anything about restrictions, the user is given an unrestricted shell.

And there are a lot of ways to get the GUIs to do that, not just the basic launcher.

With a LOT of work, a GUI environment can be set up - but it would have to be similar to the "kiosk" mode in operation. I haven't heard of a kiosk mode for gnome3, though with it's dummed down interface it may actually be easier to do...

Well... as long as the user isn't allowed to select an environment by gdm/kdm/... and gnome3 fallback can be disabled...

[Amanoo]

Well, I basically want to replace whatever interface it is the user selected (and all I have installed apart from that one other interface) is Gnome3, so I won't have to meddle with KDE settings and the like, since it simply isn't present on the system.

[jpollard]

Still doesn't prevent the user from using something other than what you install.

You will have to make some rather drastic changes to gnome3 software to create a captive account.

And there is always the users .xsession over rides what you want, unless you modify the gdm startup to NOT use it.

You also have to disable the gnome3 fallback. Oh, and you have to find a way to restrict gedit too (it can be used to create a .xsession file). and all the download functions that allow selection of application to process a file...

As I said, it is not an easy project to do. There are way too many holes in gnome to actually succeed.

BTW, one way to lock the .xsession file is to create the one you want, then mark it as immutable. This SHOULD prevent any selection from gdm from working. I won't say WILL as that is a gnome function - if it ignores the .xsession file (a fallback mode would, for instance) then all bets are off.

I have done it, but not using any of the conventional tools. A simple window manager (I used twm), NO terminal access, No editing of files, a single non modifiable menu. And the application must not do any of these either. I started the application, then twm. Nothing else. The menu only allowed restarting the application, and some status displays, but nothing else. No browsing, no compiling (a sure way around any restrictions), no file creation (another sure way). AND NO EMAIL - the editor associated with the email can be used to bypass restrictions.

Not a general use environment.