GNOME Bugzilla – Bug 681772
Last logged in field, and lastlog history button
Last modified: 2013-01-09 13:15:29 UTC
It's useful to see when you last logged in (for security reasons), and possibly even a history log of the last several logins (displayed with a button). The same is useful for someone with an administrator account type, to look at other accounts. This information should not be visible to non-administrators if looking at an account that is not their own. This would be shown on the right side of the user panel.
I'm working on it.
I depends on changes in accountsservice: https://bugs.freedesktop.org/show_bug.cgi?id=55915
Created attachment 226322 [details] [review] user-accounts: Use GtkGrid instead GtkTable This is necessary to eliminate spacing before Last Login field if there are some fields invisible.
Created attachment 226323 [details] [review] user-accounts: Add last login field
Review of attachment 226322 [details] [review]: ++
Review of attachment 226323 [details] [review]: ::: panels/user-accounts/um-user-panel.c @@ +637,3 @@ + + /* Last login: show when administrator or current user */ + list = um_user_manager_list_users (d->um); This looks like it should be a utility function, and you don't actually check for admin here. @@ +662,3 @@ + + gtk_label_set_text (GTK_LABEL (widget), time); + show = login_time && ((um_user_get_uid (user) == getuid ()) || You do a lot of work before checking whether to show it. Just don't compute it if we're not showing it.
Created attachment 226712 [details] [review] user-accounts: Add last login field
(In reply to comment #6) > Review of attachment 226323 [details] [review]: > > ::: panels/user-accounts/um-user-panel.c > @@ +637,3 @@ > + > + /* Last login: show when administrator or current user */ > + list = um_user_manager_list_users (d->um); > > This looks like it should be a utility function, and you don't actually check > for admin here. > I have found um_user_manager_get_user_by_id function, so I think it isn't necessary to make new utility function for admin checking. > @@ +662,3 @@ > + > + gtk_label_set_text (GTK_LABEL (widget), time); > + show = login_time && ((um_user_get_uid (user) == getuid ()) || > > You do a lot of work before checking whether to show it. Just don't compute it > if we're not showing it. Fixed.
There is a mockup for the last login field and the session dialog: https://dl.dropbox.com/u/5031519/system-settings/user-accounts.png
I get session information from wtmp file. The problem is that there are session information from every pseudoterminal. So if I login in to gnome and open e.g. 3 gnome-terminals there is too many records for user to be printed in session dialog: oholy pts/2 Fri Oct 19 15:05 oholy pts/1 Fri Oct 19 15:03 oholy pts/0 Fri Oct 19 15:01 oholy :0 Fri Oct 19 14:58 I can ignore output from the pseudoterminals, but e.g. ssh doesn't open screen and there is only pseudoterminal record. Missing login information from ssh is probably bad, isn't it? What all information we should to print? Is there another option to get session information except wtmp? The second thing is there isn't records in wtmp for non-local users? Should we support session history for non-local users? Is there way to get these records?
(In reply to comment #10) > I can ignore output from the pseudoterminals, but e.g. ssh doesn't open screen > and there is only pseudoterminal record. Missing login information from ssh is > probably bad, isn't it? What all information we should to print? Is there > another option to get session information except wtmp? We should probably get it through the AccountsService for now. AccountsService already reads that data in. > The second thing is there isn't records in wtmp for non-local users? Should we > support session history for non-local users? Is there way to get these records? I think it would show up the same way. Am I missing something?
Comment on attachment 226322 [details] [review] user-accounts: Use GtkGrid instead GtkTable Attachment 226322 [details] pushed as 3ce73cb - user-accounts: Use GtkGrid instead GtkTable
(In reply to comment #11) > (In reply to comment #10) > > I can ignore output from the pseudoterminals, but e.g. ssh doesn't open screen > > and there is only pseudoterminal record. Missing login information from ssh is > > probably bad, isn't it? What all information we should to print? Is there > > another option to get session information except wtmp? > > We should probably get it through the AccountsService for now. AccountsService > already reads that data in. What do you mean with that AccountsService already reads that data? Accountservice reads data from wtmp, but only about login frequency, and there aren't functions to get session information, are there? > > The second thing is there isn't records in wtmp for non-local users? Should we > > support session history for non-local users? Is there way to get these records? > > I think it would show up the same way. Am I missing something? I think it so too, maybe it isn't work for me due to my development environment.
(In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #10) > > > I can ignore output from the pseudoterminals, but e.g. ssh doesn't open screen > > > and there is only pseudoterminal record. Missing login information from ssh is > > > probably bad, isn't it? What all information we should to print? Is there > > > another option to get session information except wtmp? > > > > We should probably get it through the AccountsService for now. AccountsService > > already reads that data in. > > What do you mean with that AccountsService already reads that data? > Accountservice reads data from wtmp, but only about login frequency, and there > aren't functions to get session information, are there? No, but we might add some. What do you think Matthias, Ray?
(In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #10) > > > The second thing is there isn't records in wtmp for non-local users? Should we > > > support session history for non-local users? Is there way to get these records? > > > > I think it would show up the same way. Am I missing something? > > I think it so too, maybe it isn't work for me due to my development > environment. Sorry for misunderstanding, there are information about non-local users.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #11) > > > (In reply to comment #10) > > > > I can ignore output from the pseudoterminals, but e.g. ssh doesn't open screen > > > > and there is only pseudoterminal record. Missing login information from ssh is > > > > probably bad, isn't it? What all information we should to print? Is there > > > > another option to get session information except wtmp? > > > > > > We should probably get it through the AccountsService for now. AccountsService > > > already reads that data in. > > > > What do you mean with that AccountsService already reads that data? > > Accountservice reads data from wtmp, but only about login frequency, and there > > aren't functions to get session information, are there? > > No, but we might add some. What do you think Matthias, Ray? I have made a patch for accountservice to get login times from wtmp https://bugzilla.gnome.org/show_bug.cgi?id=681772#c2 , but there is problem with too many login records as I mentioned https://bugzilla.gnome.org/show_bug.cgi?id=681772#c10 . Probably the solution will be ignore all login records if user is logged in, but there is problem that the user isn't able to check, whether somebody else log in using e.g. ssh, when he is logged in...
Another thing, why I am asking if there is another way to get session information, is that in wtmp isn't so easy to find corresponding logout times... I thought before there will be only login times in the history dialog.
You probably want to talk to Lennart (poettering on irc). loginctl already provides some of this information (logged in since), and he has at times talked about providing a more complete wtmp replacement.
You can use the journal for this relatively easily (on F18 at least). journalctl MESSAGE_ID=8d45620c1a4348dbb17410da57c60c66 MESSAGE_ID=3354939424b4456d9802ca8333ed424a This lists all logins and logouts recorded in the journal. The ID "8d45620c1a4348dbb17410da57c60c66" is the message ID for "User logged in", the other for "User logged out". That said, I think it might be preferable to use /var/log/lastlog instead?
> You can use the journal for this relatively easily (on F18 at least). > > journalctl MESSAGE_ID=8d45620c1a4348dbb17410da57c60c66 > MESSAGE_ID=3354939424b4456d9802ca8333ed424a > > This lists all logins and logouts recorded in the journal. The ID > "8d45620c1a4348dbb17410da57c60c66" is the message ID for "User logged in", the > other for "User logged out". > > That said, I think it might be preferable to use /var/log/lastlog instead? Unfortunately lastlog doesn't solve my problem, because it isn't provide history. However journal might help me, I'll look at it...
Created attachment 227796 [details] [review] user-accounts: Add history dialog
Created attachment 227797 [details] [review] user-accounts: Add history dialog button
I have attached patches adding session history dialog using wtmp limited to x-session records. It is slightly different to mockup. There are two dates instead one, because login and logout times needn't to be at same day.
Created attachment 227822 [details] history dialog screenshot
Review of attachment 227796 [details] [review]: ::: panels/user-accounts/data/history-dialog.ui @@ +196,3 @@ + </child> + <child> + <placeholder/> Should get rid of those placeholders ::: panels/user-accounts/um-history-dialog.c @@ +91,3 @@ + list = gtk_container_get_children (GTK_CONTAINER (grid)); + for (it = list; it != NULL; it = it->next) + { { should go on the previous line. Throughout this file
Review of attachment 226712 [details] [review]: looks ok, but will need adjustment when we finalized the accountsservice api
Review of attachment 227797 [details] [review]: ::: panels/user-accounts/um-user-panel.c @@ +671,3 @@ + widget = get_widget (d, "last-login-history-button"); + gtk_widget_set_visible (widget, show); + gtk_widget_set_sensitive (widget, um_user_get_login_time (user)); Don't use a gint64 as a boolean. Shouldn't the button always be sensitive, anyway ? Showing an empty history is not so bad, imo.
Thanks for the screenshot ! Comparing it to the mockup in https://dl.dropbox.com/u/5031519/system-settings/user-accounts.png I think there are some refinements we should do: - Week display: Should do some 'smart formatting': 'This week' / 'Last week' / 'Oct 1 - Oct 8' / 'Jan 5 - Jan 12, 2011' - Date display: same story: 'Today' / 'Yesterday' / Oct 17 / Jan 8, 2011 - Time display: no leading zeros no seconds follow 12h/24h preference - I'm not entirely sure about the term 'Session History'. We are only talking about 'Login' in the rest of the dialog, 'Session' does not occur anywhere else.
Thanks for review. I'll try to fix pointed things. (In reply to comment #28) > Thanks for the screenshot ! > Comparing it to the mockup in > https://dl.dropbox.com/u/5031519/system-settings/user-accounts.png I think > there are some refinements we should do: > > - Week display: Should do some 'smart formatting': > 'This week' / 'Last week' / 'Oct 1 - Oct 8' / 'Jan 5 - Jan 12, 2011' > > - Date display: same story: > 'Today' / 'Yesterday' / Oct 17 / Jan 8, 2011 > > - Time display: > no leading zeros > no seconds > follow 12h/24h preference Shouldn't these functionality be implemented in glib? I think these smart dates are necessary also in other places and it is dull to implement it there. But if you want it I'll fix it :-)
Created attachment 227907 [details] activity dialog mockup Was thinking maybe something like this might be nice. I'm not sure I'd find the week view particularly useful since my logins span many weeks typically. Including lock/suspend activity makes sense to me since it seems one of the primary uses for this dialog would be checking for tampering or strange usage.
Created attachment 228467 [details] [review] user-accounts: Add history dialog
Created attachment 228468 [details] [review] user-accounts: Add history dialog button
Created attachment 228473 [details] history dialog screenshot
I have attached fixed patches according reviews. But still there are used 24h time format. Is there way to get 12h/24h time preference? Because g_date_time_format doesn't provide internationalized time in this format.
I have found org.gnome.desktop.interface clock-format, so I'll fix it later...
Created attachment 228565 [details] [review] user-accounts: Add history dialog Fixed 12/24h time formats...
(In reply to comment #36) > Created an attachment (id=228565) [details] [review] > user-accounts: Add history dialog > > Fixed 12/24h time formats... Don't. This is a *clock* format, not for printing time.
(In reply to comment #37) > (In reply to comment #36) > > Created an attachment (id=228565) [details] [review] [details] [review] > > user-accounts: Add history dialog > > > > Fixed 12/24h time formats... > > Don't. This is a *clock* format, not for printing time. So what's the correct way to follow 12h/24h time preference? What about getting preferred time format string using nl_langinfo and check if there is %p/%P format specifier to detect 12h format?
Created attachment 229635 [details] [review] user-accounts: Add last login field Fixed date format and some bugs.
Created attachment 229636 [details] [review] user-accounts: Add history dialog Removed 12h/24h time formats using clock-format. On the bases of conversation with Bastien correct time formats will be fixed later, because there are more project with same problem. Please review attached patches.
Created attachment 230178 [details] [review] user-accounts: Add history dialog Fixed wrongly removed declaration and changed size policy in history dialog.
Review of attachment 229635 [details] [review]: Patch fails to apply on master. ::: panels/user-accounts/data/user-accounts-dialog.ui @@ +442,3 @@ + <property name="visible">True</property> + <property name="xalign">1</property> + <property name="label" translatable="yes">_Last Login</property> Why the mnemonic? ::: panels/user-accounts/um-user.c @@ +310,3 @@ + g_return_val_if_fail (UM_IS_USER (user), 0); + + return user->props->login_time; Don't you want to set it to something else so you can detect the LoginTime property not being set?
Review of attachment 230178 [details] [review]: You need to disable the history button if LoginHistory isn't available. ::: panels/user-accounts/um-history-dialog.c @@ +183,3 @@ + /* Find first record for week */ + from = g_date_time_to_unix (um->week); + to = from + 3600 * 24 * 7; g_date_time_add_weeks()?
Created attachment 230211 [details] [review] user-accounts: Add last login field Fixed unnecessary mnemonic and inapplicability to master.
Created attachment 230212 [details] [review] user-accounts: Add history dialog Fixed time computing using g_date_time_add_weeks and disabling history button.
Created attachment 230272 [details] [review] user-accounts: Add last login field Fixed wrong time format strings.
Created attachment 230273 [details] [review] user-accounts: Add history dialog Fixed wrong time format strings.
Hi Ondrej, I'm really sorry for keeping better track of this. Well done for carrying it through - it looks like you are making some good progress. Looking at the latest screenshot [1], I can see a few small issues: * window title should be set rather than including a heading in the window itself * window isn't tall enough by default (and should have a larger minimum size) * repetition of the date in two columns Also, I have to say that I rather like Jon's suggestions in comment 30. Perhaps we could develop this in the direction he outlined? A good first step would be to make each row into a single event, such as "Unlocked" or "Session Started". Apologies again for not giving you better guidance. [1] http://bugzilla-attachments.gnome.org/attachment.cgi?id=228473
I don't disagree that it would be nice, but we currently have no easy way to get a unified history about the kinds of extra events that Jon used to make his mockup look nicer: lock/unlock, suspend/resume, power on/off, account creation. Adding these kinds of events might be possible when we start talking directly to the systemd journal.
Created attachment 230518 [details] revised mockup I'm afraid that, without events like lock and unlock, this dialog won't be particularly useful. That said, here's a revised mockup which just shows session start and end events.
Attachment 230272 [details] pushed as 691a258 - user-accounts: Add last login field Marking history dialogue as needs-work, as per designer comments. Sorry about the churn :(
Created attachment 230967 [details] [review] user-accounts: Add history dialog Fixed patch according designer comments.
Created attachment 230968 [details] history dialog screenshot
Review of attachment 230967 [details] [review]: There's a couple of bugs, maybe related: - the weeks advertised seem to last 8 days. I see "Nov 19 - Nov 26" when it should say "Nov 19 - Nov 25" - "2 weeks ago" (shown as "Nov 26 - Dec 3") shows up empty. I dumped the login history, and I logged in/out multiple times during that week.
(In reply to comment #54) > Review of attachment 230967 [details] [review]: > > There's a couple of bugs, maybe related: > - the weeks advertised seem to last 8 days. I see "Nov 19 - Nov 26" when it > should say "Nov 19 - Nov 25" > - "2 weeks ago" (shown as "Nov 26 - Dec 3") shows up empty. I dumped the login > history, and I logged in/out multiple times during that week. Incorrect date range is only plus one mistake and it is (unfortunatelly) unrelated with missing records. Please, send me outputs of commands (with correct uid): last dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.DBus.Properties.Get string:'org.freedesktop.Accounts.User' string:'LoginHistory'
Created attachment 231909 [details] history-debug.txt
(In reply to comment #56) > Created an attachment (id=231909) [details] > history-debug.txt Thank you. There is a line in the output of last command: hadess :0 :0 Fri Nov 23 17:32 - 17:12 (9+23:40) According that line you logged in on Nov 23 and logged out after 9 days (Dec 3). So there aren't any login/logout records for the week Nov 26 - Dec 2 and the history dialog is correctly shown empty, or am I overlooking something?
Created attachment 231911 [details] [review] user-accounts: Add history dialog Fixed incorrect time range.
(In reply to comment #57) > (In reply to comment #56) > > Created an attachment (id=231909) [details] [details] > > history-debug.txt > > Thank you. There is a line in the output of last command: > > hadess :0 :0 Fri Nov 23 17:32 - 17:12 (9+23:40) > > According that line you logged in on Nov 23 and logged out after 9 days (Dec > 3). > So there aren't any login/logout records for the week Nov 26 - Dec 2 and the > history dialog is correctly shown empty, or am I overlooking something? Unless I'm mistaken, there's login data for the same period of time on :0 as well, no? I'm not sure how to read that data as there's no explanations of the columns or the format, even in the "last" man page.
(In reply to comment #59) > (In reply to comment #57) > > (In reply to comment #56) > > > Created an attachment (id=231909) [details] [details] [details] > > > history-debug.txt > > > > Thank you. There is a line in the output of last command: > > > > hadess :0 :0 Fri Nov 23 17:32 - 17:12 (9+23:40) > > > > According that line you logged in on Nov 23 and logged out after 9 days (Dec > > 3). > > So there aren't any login/logout records for the week Nov 26 - Dec 2 and the > > history dialog is correctly shown empty, or am I overlooking something? > > Unless I'm mistaken, there's login data for the same period of time on :0 as > well, no? I'm not sure how to read that data as there's no explanations of the > columns or the format, even in the "last" man page. You can found some additional limited information in the "wtmp" man page, but there isn't detailed explanation for records. However I'm reading these lines as: :0 :0 ...... new X session (new for every login) pts/? :0 ... new pseudoterminal (new for every opened terminal)
Rebased for the libaccountsservice usage, and GResources changes. Attachment 231911 [details] pushed as 324d1ce - user-accounts: Add history dialog