-
Notifications
You must be signed in to change notification settings - Fork 1
/
TODO
220 lines (182 loc) · 10.3 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
Things on the TODO list:
1. Rework all of the debug output. Set it so that if DEBUG=-1,
then debug information/code isn't compiled in at all, if
DEBUG >= 0, then debug information/code is in there and
that level of debugging (for DEBUG >= 1) will represent
the debug level. XXXXXX other stuff.
2. The current xlock check is a little cheesy, since a user can
avoid the checks by running it under a different name than
chosen at compile time. I would like to rewrite the checks
to see if a program has grabbed full control of the keyboard,
and if one does, it is probably an xlock program. I'm not
sure how I would work it all right now, but idled might have
to simply notice the first time it found such a program and
see if one is still running 'idle time' minutes later. This
is imperfect, however, as it is possible for the user to exit
the xlock program for a very short period of time (less than
'sleep' seconds, as specified in the conf file) and start a
new one. But, I would like to do something.
In testing of this, it isn't going to work, since some other
programs also grab the keyboard occasionally, and there would
be no way to know if an xlock program is what is grabbing it
or not. Ideas?
3. Make an exempt-command feature??? Suggestion from Chris Jackman:
Have you thought about allowing a command name exemption?
Say you have long running program that is valid but doesn't
have any tty input. (Let's say the controlling process for
a xterminal login session.) What happens is that even though
your subshells are not idle the controlling tty/process looks
idle and is nuked killing everything you have running. If you
could say ignore tty's with processes called "xinitremote" and
have this as idled.cf parameter that would solve the problem.
This could also be useful for any long running processes that
might be valid to have on a system for longer than any given
timeout.
The format of the command will probably be something like this:
exempt command session <command name>
Exempts the user's tty from session limits if the
user is running the specified command.
exempt command idle <command name>
Exempts the user's tty from idle logouts if the
user is running the specified command.
4. A similar possibility to the exempt-command is to not consider a
tty as idle if the children of the controlling shell are
still active (ie. backgrounded processes are working, but
the shell itself is idle). This sounds like using system-
dependent process walking, though, which is messy. Also,
how is activeness of a process determined? Any ideas?
5. Perhaps add an option to run some external program when a user
gets warned. Users here manage to not notice the idled warnings
and get logged out. Some have taken to running a program to
play a sound file if they are idle for just under the logout
time here. Perhaps I will accommodate them by letting idled
warn them in a louder fashion (or maybe even letting the
specific user choose what idled does [I don't think so, here]).
6. Idled seems to not work on some systems because the killing
of the user does not result in the utmp entry for the user
being removed, though the user has actually been logged out.
I'd like to see if I can find a way to fix that.
7. Would like to add this:
Suggestion from John Coy:
I do have one request and was wondering if you might consider adding
this feature: adding a check to logout a user in a particular group
during a specified time frame. For example, if a user was in the group
'daytime', he would be logged off if the hour was between 3pm - 3am. This
would be a very useful feature since it would allow the creation of
'non-prime-time' accounts.
Probable format:
primetime 15:11 3:14 /* Note: 24 hour mode! */
session primetime group daytime 10
^^^^^^^^^^^^^^^^ Any valid session stuff here
timeout primetime group daytime 10
^^^^^^^^^^^^^^^^ Any valid timeout stuff here
Perhaps have 'primetime' first for all:
primetime hours 15:11 3:14 /* Note: 24 hour mode! */
primetime session group daytime 10
primetime timeout group daytime 10
This would operate on a session limit basis, where the user, during the
prime-time hours, would be limited to some number of minutes. During
the non-prime-time hours, only the usual session limit / idle timeouts
would be in place. Multiple logins should also be based on prime-time
hours.
*Perhaps in the mean time, implement a simple 'timerange' to specify
when idled is function, or non-functional. Clearly not as much
power, but easy to implement. Using this, two idled's could be running
with different configuration files covering different time chunks.
8. I'd like to get rid of the system dependent file flushing in warn.c.
I've looked at tcflush() to see about using it to slaughter all
unread/unwritten data hoping that it could be used as a generic
system-independent method. It didn't work (unless I want to rewrite
all the output in warn.c to use open() and write() calls). So, I'm
still looking. Any help would be appreciated.
9. Perhaps implement some sort of idle process slaughtering, as well
as session limit slaughtering. This can have an effect when the
normal idled wouldn't in the situation of users 'rsh'ing a process
to another machine or backgrounding a process.
10. Add an option to offer multiple warnings, say at 10 minutes before
death and at 2 minutes. This would be configurable, of course.
11. Add an option to have warnings also logged in the logfile.
12. Finish the pidkill() procedure in zap.c. Make notes in the
appropriate docs about being able to choose the order of the
kill signals, such as HUP, EMT, KILL, or HUP, TERM, KILL,
or whatever is best for that system.
13. Implement overall session limits, so that users may log on
10 different times for only a few minutes each, but the
total time of those logins will be limitted.
Suggestion by Douglas Brewer <[email protected]>.
14. Perhaps implement idlemethod based on a per-user basis,
such as allowing login, user, tty, group commands for it,
as well as a default?
15. Perhaps add an option so that 'session refuses' will either
refuse a user from all hosts if he was killed by a
'session host' command, or to refuse the user ONLY from that
host. Perhaps something like this:
session hostrefuse all
or
session hostrefuse host
16. Allow setting of 'multiples' by login/group/tty specification,
instead of the current general setting.
17. Perhaps allow the use of wildcards in login/group/tty
specifications, such as
exempt group P* timeout
18. Perhaps change the configuration reading so that names
(such as hostnames and usernames) can have any character
in them. At least ensure that '.' and '-' can always be
used.
******************************************************************
Things that will most likely be an a 2.00 release (perhaps sooner,
based on how much time I find):
******************************************************************
1. Dynamic policy adjustment:
This would require a sub program to communicate with the
idled process to change the loaded policies without change
of the configuration file. Such a change could be done
like this:
idled_adjust -u joe -i 30
to change the allowed 'i'dle time for 'u'ser joe to 30 minutes
idled_adjust -g students -s 20
to change the 's'ession limit for 'g'roup students to 20 minutes
idled_adjust -f staff -e all
to 'e'xempt the users in the staff 'f'ile from all checks
idled_adjust -cf config
to change the configuration file to 'config'
Except for the config file change, these could be done on the
current logins of joe, students, and staff only, perhaps with
the addition of a '-l' option.
The purpose of this could be something like the following
examples:
a. Joe is going to be popping in and out of the lab while
performing some critical time-consuming commands. He
needs to have more than 10 minutes of idle time. To
help him out, the system administrator kindly increases
Joe's allowed idle time for the current login to 30
minutes. With the dynamic policy adjustment, the config
file will still be correct for future situations.
b. A system may have users dialing in on their own phone
bill and on 1-800 lines. The users on the 800 lines
should be session limited. When the user logs in on
an 800 line, an idled_adjust command would be issued
to tell idled to attach a session limit to that user
for the current login.
It is more of the "for the current logins only" type of changes
that I see a real use for this.
I had more to say here, but I forgot. Maybe it will come to me.
2. A "plug-in" system:
The two places in idled where some sort of plug-in might be
useful (as I see them) are:
a. The idle process determination
b. The killing Process -- perhaps warn as well
Reasoning:
a. We have a portmaster modem server that has special
commands to monitor session times and kill sessions.
Idled's current idle/session methods have no way
to check such things, and a "plug-in" here would
do the trick.
b. The portmaster would also require some killing
mechanism, and a "plug-in" would do here, as well.
Also, this would allow for a different style of
kill, as well as possibly allow functionality for
idled on a system that it otherwise doesn't work
on.
c. Something else I just forgot. I think I need to go
eat dinner. :-)