Should not be able to restrict myself

Just confirming.

I was thinking we should add an 'Options' tab with a check box to
limit or not members of admin (or wheel?) group, the value would be
saved in timekpr.conf
Maybe postpone this for the next release? :)

Good idea Savvas!

Save it for later!

This is really just an annoyance. But it would not be wise to limit administrators (they would be able to 'unlimit' themselves anyway...).

will do :)

While I personally love options. Knowing that my wife WILL accidentally lock herself out when changing things, I think it would be better to eliminate the primary administrator from being limited. She does have her own login with admin rights as do I. I don't want her to have the ability to lock me out as the primary admin user. If she locks herself out it won't be that bad provided she CAN'T lock out the primary account. It's a safety net. I know I'll be here at work late at night, and the phone will ring... Honey! I've locked the computer by accident. No one can login. Tell me how to fix it. If she locked me out, there is no fix until tomorrow. As unlikly as you may think this sounds, it will happen.

My vote goes with Even’s first idea. Primary Administrator can’t be limited.

Just my 2¢

-Charles

Defining the first user ever created is a tricky thing to do I'm afraid.
I don't think there is a thing such as a primary administrator, if we
look at it in a broad manner, anyone can make the primary
administrator as user id 1002, and make the first user with id 1000
normal... I hope you understand what I mean :)

I'll disable it for now for userid 1000 and userid 500 (fedora), but I
think that would not be recommended for later releases

applying fix

rev #117

Understood perfectly. There's only so much that can be done.

updated in #121 (using UID_MIN from login.defs to define first user)

Can you checkout the beta 2:
http://savvas.radevic.com/timekpr/timekpr_0.2.2~b2_all.deb

I'll get right on it. At work right now (as usual), I'll try to have some results by tomorrow. I plan to give it a rigorous test drive this weekend.

Follow-up Report: After testing for several days on multiple systems, I'm happy to report EVERYTHING is working flawlessly sp far. The UID_MIN fix seems to be the perfect ticket here. Thanks for the hard work on this beta release.

I have the following situation: I have multiple PCs that I am responsible for, I force every person to have same uid on all my PCs. On many locations (Kids home, my home, grandparents) the Kids have a login and there are different grown-ups around to restrict kids access. None of the grown-ups (except me) has admin rights. All grown-ups should be able to restrict the access of all kids, but no grown-up should be able to restrict another grown-up.

My setup for timekpr is as follows:

/etc/sudoers:
...
User_Alias TIMEKPRS = administrator, parent1, parent2, grandpa, grandma
...
TIMEKPRS ALL=(root) NOPASSWD: /usr/bin/timekpr-gui ""

this survives a reinstall of timekpr. However, the next fix I apply always manually after a reinstall.

/var/lib/python-support/python2.5/timekpr-gui.py
def isnormal(username):
    ...
    elif userid == 1001 or userid == 2000 or userid == 2004 or userid == 2005 :
        return False
    ...

of course, 1001=parent1, 2000=parent2, 2004=grandpa, 2005=grandma.

I don't think this is the best implementation, but it is the simplest for me. I think it is very important, that you DO NOT use a "root" group to determine the "grown-up/kid" state. Maybe creating an own group "timekprs" would make sense...

How do I undo this fix? I have computers where uid 1000 is not an admin and needs to be restricted.
Why not just check to see if users are members of the admins group? That seems more to the point.

In /usr/share/python-support/timekpr/timekpr-gui.py find

def isnormal(username):

change

if userid == uidmin:
        return False
    elif uidmin < userid <= uidmax:
        return True

into

if userid == <your admin userid>:
        return False
    elif uidmin <= userid <= uidmax:
        return True

It should work after this. We will try to fix this in a later release!

If you apply this "fix" it will be overwritten if you update timekpr.

Savvas, would it be possible to get the username of the user running timekpr-gui? Then make it impossible to restrict oneself?
What about sorting the list of users in reverse order. That way the pre-selected user would not be the first user created (who, most probably, is an administrator).
Make a list of users NOT to be restricted and check against this when populating the drop down? The list could be created when a user first starts timekpr-gui.

I am just making suggestions here. But I think we need to get this sorted out...

You have to remove two lines in timekpr-gui.py file:
 #FIXME: Temporary fix for: https://bugs.launchpad.net/bugs/286529
 if userid == "1000" or userid == "500": return 0

> Savvas, would it be possible to get the username of the user running timekpr-gui? Then make it impossible to restrict oneself?

Looking for it, I'll let you know :)

os.getlogin() = active user

Savvas, I think those lines was removed before we released 0.2.2...

I will have a look at os.getlogin()!

Correct, sorry, I was looking at the old #117 revision

Even, can you test revision #202 ?:)
It's supposed to hide the active user

No, it did not work. Here is the error:
  File "/usr/share/python-support/timekpr/timekpr-gui.py", line 585, in
<module>
    timekprGUI()
  File "/usr/share/python-support/timekpr/timekpr-gui.py", line 150, in
__init__
    if isnormal(userinfo[0]):
  File "/usr/share/python-support/timekpr/timekpr-gui.py", line 70, in
isnormal
    if username == getlogin(): return False
OSError: [Errno 22] Invalid argument

Sorry, I don't have time to do more testing right now. I had to do some changes (import os.getlogin() among other things). So bzr pull before you do anything more!

I also found this:
http://bugs.python.org/issue678077

stating that os.getlogin() is not good! I tried pwd.getpwuid(os.getuid())[0], but that returned 'root' as user...

Ah, thanks - I tested #203 locally - it works, thanks!

> pwd.getpwuid(os.getuid())[0], but that returned 'root' as user...

I know, that's why I suggested using getlogin. :)

The other way to get this is to use:

from os import getenv
getenv("LOGNAME")
getenv("SUDO_USER")

I think the solution Even suggested fits... no need to check for other administrators, but perhaps in the future to make a way to customize the list :)

#203 does not work in my VMs. When I start timekpr-gui with

gksu timekpr-gui
or
gksudo timekpr-gui

I get the error above.

When I run it with

sudo timekpr-gui

it works fine. But I don't think you should run GUI-apps with sudo (also the menu launcher uses gksu).

OK, then we have a problem.

We could use the values I mentioned above:
$ gksu -- python -c 'from os import getenv ; print(getenv("LOGNAME"),getenv("SUDO_USER"))'
('root', 'forger')

I'll test a check locally and let you know

How about this?
from os import remove, mkdir, geteuid, getenv

def isnormal(username):
    #FIXME: Hide active user - bug #286529
    if (getenv('SUDO_USER') and username == getenv('SUDO_USER')) or username == 'root':
        return False

Tested with gksu, gksudo and sudo.

Err... actually I don't think there's a need to check username == 'root', since root has user id 0.

I think this should do fine:

from os import remove, mkdir, geteuid, getenv

def isnormal(username):
    #FIXME: Hide active user - bug #286529
    if (getenv('SUDO_USER') and username == getenv('SUDO_USER')):
        return False

rev. 204 - I hope there are no problems now :)

#204 works fine here!

> #204 works fine here!

Thanks for testing it - thank you everyone for your input! :)

milestone 0.3.0

milestone 0.3.0