Missing privileges, for system actions, without consolekit

[Thanatermesis]

Seems like when autologin is set, the user logins with less privileges, so all the system actions are grayed out (reboot/shutdown/suspend/hibernate)

autologin should use the same login system as a normal user (since its the mode that works correctly) also to maintain compatibility between modes and not turning in future bugs or hard to catch ones

susbscribers: @triantares

[wltjr]

Thank you for the report. That is a rather strange issue. I have been stuck using autologin since I ran into issue #34. I do not have any less privileges when logged into Enlightenment or in general. That might be due to Enlightenment relying upon /etc/enlightenment/sysactions.conf, which controls permissions for those actions and others. The login code is not any different in autologin, only where the login credentials come from; config file rather than user input. Although, there could be some issue I am not aware of based on my usage and testing.

What desktop are you logging into? Have you run the groups command or others to verify groups or permissions were missing after autologin?

[Thanatermesis]

The login code is not any different in autologin

ah! thats important information

I use last E (git) here, and its easy to reproduce... so! if theres no difference in the login method used, the only difference that comes to my head is the time required to login (direct fast autologin VS human interaction delay), so maybe the issue happens from the .service conf which will need to have some dependencies set up before the desktop itself (E) starts, something like dbus or similar, hum...

[wltjr]

The code should be the same, but it is invoked in different places, regular and autologin. There might be an issue there, but I am not able to replicate in order to determine if that is the issue or not.

There should not be any difference between manual vs auto login. I do not think the speed of autologin is the issue, but it could be. There is a 30 second delay already for xcb when using autologin. Without that delay, it has issues connecting as xcb seems to require a delay. You could try to increase that delay, but I do not think it will make a difference.

It is possible that the problem is due to a missing dependency. It seems, the major difference in your autologin setup vs mine is systemd vs openrc. I do have dbus configured to start on boot, and it does start before entrance, despite lacking an implicit dependency on such. Looking at the code e_sys_main.c and e_system_main.c, I cannot confirm if dbus is used or not. But that should be easy to test and rule in/out.

Otherwise, it maybe user/group related. Not sure if you need to be a group member of the wheel group, or one of the other default groups in sysactions.conf. It seems to use /usr/lib64/enlightenment/utils/enlightenment_sys, that has SUID set. Seems that binary is related to sysactions.conf file.

[Thanatermesis]

There is a 30 second delay already for xcb when using autologin.

Mmh, im not sure that this delay is correct, let me explain:

the boot (since power-on to desktop started) doesn't wait 30 seconds, the entrance step takes probably less than 1 second (directly autologins), so where happens these 30 seconds? what makes sense to me is that this delay should make entrance "wait" before the desktop is started, but i don't see this behaviour happening

About dbus, E uses dbus, and it should be a very needed thing to keep compatibility, my suggestion is to "want" to start all those type of services (if exists) as possible (consolekit, policykit, dbus, etc...) to keep a correct compatibility consistency on desktops (by other side, would be needed to first know which one is causing the issue in the bug here, assuming that this is the issue)

Otherwise, it maybe user/group related.

Mmh, that should be the same between "autologin" and "normal login" mode, thats why i said the issue should rely on the speed of boot

[wltjr]

The delay comes just after login and session start. If you monitor the log file you should see the delay just after main() login user and before _entrance_session_wait() session running pid 2738, waiting....

It should be minor to add startup dependencies like dbus or other and see if that resolves the issue. That should just require modifying the .service file, adding Type=dbus for dbus, or Requires= or After= for other stuff. Although, I am not sure what else could be required beyond dbus and consolekit. There is no code support at the moment for logind/elogind, which will likely go through dbus to start that session vs invoking via CLI like spawny does.

I do not think the issue is related to speed of boot but order of services started. Unless, something that is required is failing to start. When logging in manually, the delay between entrance start and user login is likely allowing other stuff to finish starting.

[Thanatermesis]

I do not think the issue is related to speed of boot but order of services started. Unless, something that is required is failing to start. When logging in manually, the delay between entrance start and user login is likely allowing other stuff to finish starting.

yeah, that's what i meant with the speed of boot :)

About Type=dbus, if im not wrong that is about telling systemd that includes a dbus service, in order to be managed as a dbus service, and entrance is not (if im not wrong), the desktop may have dbus but not entrance as a service itself

[wltjr]

I likely misread the documentation on systemd service files, this section. I guess just a regular Requires=dbus.service and/or After=dbus.service for entrance.service. Type seems to bring in dbus.socket, which would likely not be enough.

[Thanatermesis]

Mmmh, I have played a lot with it and I have no way to make it working

Added different dbus requirements, tried to run as the LAST service, and even included a "sleep 10" in the ExecStartPre

As a final test, I have disabled the service, rebooted and then (no graphical system run) I logged into the console tty, as root, and run "entrance --nodaemon", since its configured with autologin it did autologin directly to E23, and still having the same issue

So the problem should be on the differences on how entrance logins the autologin mode VS the normal mode aparently 🤔

[wltjr]

Well, it seems, we can rule out dbus not being started as the cause of the issue. It is still pretty strange that there are differences in your system between manual and autologin. It would be beneficial if I could replicate the issue, that would really help with tracking down the cause and coming up with a solution. I will have to look further into this when I get a chance.

Thank you very much for your time and effort looking into this issue, and of course, the initial report as well. I am sorry that you are experiencing this issue. Hopefully, I can get some time to look into and resolve it soon. I have a backlog of issues growing...

[Thanatermesis]

It would be beneficial if I could replicate the issue

that could be fast to do:

• download elive beta version
• install it on a real machine or a virtual one
• install enlightenment and entrance packages
• ready :)

[wltjr]

Great, thank you very much for the suggestion! That should help replicate the exact environment and issue your experiencing. Now, I just need the spare time...

Speaking of elive, was there an animated control center type UI that had voice audio? There was some version of E back in the day, E17 I believe, that had such an interface. I have been curious who made that and where it went. From talking with E devs, they do not recall it ever existing, but I know it did. I think it was unique to a version of elivecd. Do you recall such? Thanks!

[Thanatermesis]

Speaking of elive, was there an animated control center type UI that had voice audio?

I think you mean e16, which had themes with sound, in fact the version beta of elive actually uses e16 (thats why i said to install E (running "api enlightenment") for the entrance tests), and the provided theme of e16 has already those voices included and enabled for the settings panel :)

[wltjr]

Great, finally, someone knows what I am talking about. I did not realize it was E16. I tried to download the elive 32bit beta, but I think something went wrong. I submitted my email address and I received the confirmation email. I clicked on the link, but there was an error message, I assume, in the area where there would be a link to download it from.

Once I can download the beta, I will install E and Entrance, then hopefully, I will be able to replicate the issue your experiencing for further investigation.

[Thanatermesis]

Yes you will replicate the issue without problems

Mmmh, thanks for report that, unfortunately im not able to reproduce the issue (following your steps), the confirmation link is for subscribing to the newsletters (you got the error on this link? mmh it worked for me..), and then you should have received the download link in around 2 hours (confirming or not you should have received it)

I have been working on this system a few days ago so i hope you didn't got an error from these code updates / tests

In any case, can you try again? if you still having the error please tell me which one / what it says so I can solve it, so could be very bad if visitors are unable to download elive from the website due to an error 🤔

[wltjr]

@Thanatermesis ok, I tried it again, and I ran into the same issue. Here are the two links I received in email, 1 and 2. I will remove from this posting, since they do not seem to expire. I hope that helps.

[Thanatermesis]

Thanks, alright the (your) links returns an error, maybe because the email you used (it works with gmail for me), can you tell me what is your email so that I can check what is happening with it ? for privacy and/or to talk better about the issue of Elive you can answer me via thanatermesis at gmail :)

[Thanatermesis]

Hi again,

I tried to sent you an email from my gmail, but I have a mail delivery error, can you write me from some email where I can communicate with you? In fact it looks like all the issue is caused by a hardbounce state with your email, and from my gmail I have this message trying to write you:

554 Mail appears to be unsolicited -- send error reports to admin@ [cut] ...

[wltjr]

Sorry about that, seems emails were not making it past my spam proxy ASSP. I have already replied to you directly via your email address.

[Thanatermesis]

I dont remember now if you finally was able to download the isos to test or not, but I will wait for your news :)

[wltjr]

@Thanatermesis yes, I was able to download the ISOs. I need to re-download the 64-bit version, as I had run out of space due to other downloads. I did not have any problems with the link you emailed me, thank you for that! I have just been short on time. I should be able to test it out this weekend, and hopefully, replicate the problem you experienced.

[wltjr]

@Thanatermesis I was finally able to replicate this issue. It looks like this is a result of building entrance without consolekit support. It has nothing to do with autologin. Consolekit is being removed from Gentoo, so it looks like I will need to see about a solution for this sooner, rather than later. I still have yet to play with the elive iso's, but that may not be necessary for this issue at least, it maybe for other issues.

[Thanatermesis]

In fact if im not wrong, consolekit has been already removed from Debian Buster time ago, so yeah seems like not used anymore

[wltjr]

Yes, it is legacy stuff. Most use logind in some form either from systemd, or elogind. I started some work to integrate with logind via dbus, but it is far from complete, or even working. I may have to just bite the bullet and go the crude way by invoking logind session via cli, like how spawny does it. At least, until, I have time to do the direct integration via dbus.