This is caused by an incompatible Fedora specific kernel change.

Fedora added a kernel patch that makes it impossible to read /sys/power/disk for userspace processes lacking CAP_COMPROMISE_KERNEL. When logind tries to figure out whether hibernation is available it needs to read that file. logind runs on minimal capabilities, and lacked CAP_COMPROMISE_KERNEL hence. As a result loging always reports CanHibernate() as "na".

This is a recent issue only, as the patch was very recently added only, apparently only for testing?

userspace libraries such as libcap don't know the capability. We rely on libcap to translate the capability bits to strings and back for us. Given that libcap doesn't know this cap we hence can't even work-around this kernel breakage.

adding a capability check where none was required before broke compatibility with userspace that run at minimal caps.

also, protecting reading a file like that (in contrast to writing) doesn't make much sense anyway. it's fine if unprivileged code learns that the machine can hybrid suspend.

Not sure what to do about this. Easiest would be to revert the kernel patch. Otherwise we can work around this by adding CAP_COMPROMISE_KERNEL, but for this is nasty, since the patch isn't upstream, libcap doesn't support it, and adding it to our upstream systemd code would break things for folks who run a kernel without that bit.

Anyway, reassigning to kernel.

CAP_COMPROMISE_KERNEL is the capability added for UEFI Secure Boot.  It should only make a difference if your machine is actually booted in Secure Boot mode.  Hibernate is disabled for everyone in that case.

On my machine with Secure Boot enabled, this is working as expected:

[jwboyer@localhost ~]$ cat /sys/power/disk 
[disabled]
[jwboyer@localhost ~]$ sudo su -
[root@localhost ~]# cat /sys/power/disk 
[disabled]
[root@localhost ~]# 

I'll look at why we get differing results on non-Secure Boot machines.  It's a simple bug.

I see the same behaviour as an ordinary user:
  [kay@lon ~]$ cat /sys/power/disk 
  [disabled]

  [kay@lon ~]$ sudo cat /sys/power/disk
  [platform] shutdown reboot suspend 

This is a laptop booted in EFI mode, but without secure boot.

(In reply to comment #3)
> I see the same behaviour as an ordinary user:
>   [kay@lon ~]$ cat /sys/power/disk 
>   [disabled]
> 
>   [kay@lon ~]$ sudo cat /sys/power/disk
>   [platform] shutdown reboot suspend 
> 
> This is a laptop booted in EFI mode, but without secure boot.

Right.  As I said, that's a bug.  I see the same thing on my non-SB machines.  The patch should do absolutely nothing if Secure Boot isn't enabled.  I'll fix it shortly.

OK, should be fixed.  Will be in f18 3.7.2-205 and rawhide whenever it builds again.

Secure Boot machine:

[jwboyer@localhost ~]$ cat /sys/power/state 
mem 
[jwboyer@localhost ~]$ cat /sys/power/disk 
[disabled]
[jwboyer@localhost ~]$ sudo su -
[root@localhost ~]# cat /sys/power/state 
mem 
[root@localhost ~]# cat /sys/power/disk 
[disabled]
[root@localhost ~]# uname -a
Linux localhost.localdomain 3.7.2-204.1.fc18.x86_64 #1 SMP Wed Jan 16 20:57:02 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# 

Non-Secure Boot machine:

[jwboyer@vader ~]$ cat /sys/power/state
standby mem disk
[jwboyer@vader ~]$ cat /sys/power/disk
[platform] shutdown reboot suspend 
[jwboyer@vader ~]$ sudo su -
[root@vader ~]# cat /sys/power/state 
standby mem disk
[root@vader ~]# cat /sys/power/disk 
[platform] shutdown reboot suspend 
[root@vader ~]# uname -a
Linux vader 3.7.2-204.1.fc18.x86_64 #1 SMP Wed Jan 16 20:57:02 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@vader ~]#

kernel-3.7.4-204.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.7.4-204.fc18

kernel-3.7.2-204.fc18.x86_64 fixes it only partially, CanSuspend() returns "yes" while CanHibernate() still returns "na", unlike upower which correctly says the hibernation is supported.

Please provide the output of the commands I ran in comment #5.  Also the output of "dmesg | grep -i secure"

[ltinkl@goblin ~]$ cat /sys/power/state
mem

[ltinkl@goblin ~]$ cat /sys/power/disk 
[disabled]

[root@goblin ~]# cat /sys/power/state
mem disk

[root@goblin ~]# cat /sys/power/disk
[platform] shutdown reboot suspend

[root@goblin ~]# dmesg | grep -i secure
[    2.154022] sdhci: Secure Digital Host Controller Interface driver

[root@goblin ~]# uname -a
Linux goblin 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Fascinating...

Can you attach the full dmesg output?  Also, as a normal user, the output of 'cat /proc/self/status' ?

Oh, nevermind.  3.7.2-204.fc18 doesn't have the fixes in it.  You need 3.7.3-201 or newer.

Note that comment #6 is 3.7.4-204, not 3.7.2-204.

Package kernel-3.7.4-204.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.7.4-204.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1443/kernel-3.7.4-204.fc18
then log in and leave karma (feedback).

kernel-3.7.4-204.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Verified, kernel-3.7.4-204.fc18 fixes the problem for me

Obviously breaking logind is a bad thing here, but logind really shouldn't be blindly dropping capabilities. The entire point of capabilities is to prevent processes from being able to do things that you would otherwise expect the process to be able to do, so you can't safely make the assumption that dropping capabilities you don't know about will leave you with the functionality you want.

Well, that's a bit contradicting the "least privileges" idea. 

It's a fundamental issue with the capabilities model: since programs list exactly the privileges the need you can never make the privileges logic anymore fine-grained, since existing apps will then miss those new capabilities.

You say "The entire point of capabilities is to prevent processes from being able to do things that you would otherwise expect the process to be able to do."

However, I am pretty sure the more common understanding goes the other way: "The entire point of capabilities is to allow processes to do exactly the things they should be allowed to do, and not more." 

Most capabilities examples suggest the latter definition. For example, the example right in front of the libcap-ng example:

http://people.redhat.com/sgrubb/libcap-ng/

And this is implemented that way quite comprehensively currently. For example, all file system capabilities on Fedora are actually set to limit the set to a minimum, rather than just dropping a few. (Hint, just type "filecap" into a shell).

Feel free to bring this up with the capabilities folks, but systemd is currently perfectly in line with how people do implement capabilities all across the board.

You agree that this means that adding any new capabilities will break existing userspace, though?

(In reply to comment #17)
> You agree that this means that adding any new capabilities will break
> existing userspace, though?

If done without care, yes.

However, the recent CAP_SYSLOG addition actually did get it right AFAIR, because they actually check for either the new (CAP_SYSLOG) or the old capability (CAP_SYS_ADMIN), and grant access for either. That way clients can use the new, fine grained CAP_SYSLOG and that's all they need, or they can use the old, coarse CAP_SYS_ADMIN and still work.

of course, the same scheme doesn't really apply to the CAP_COMPROMISE_KERNEL issue, since it defeats the point leaving CAP_SYS_ADMIN as an alternative cap needed for hibernation...

It doesn't seem to be possible to handle the case where capability checks are added where none previously existed, though - there's no way to check for an alternative there. The risk of doing it the other way (only drop capabilities you know about) is that if a new capability permits something that was previously forbidden, you'll have more privileges than you expected. So both approaches do seem to be broken and I have no idea how to add new capabilities without breaking existing userspace.