[erik_seaberg]

“Logged in”? Does this seriously not accommodate cronjobs? Well, this isn't the first time they have ignored non-interactive and distributed uses, and it always seems like they're targeting a game console rather than a real computer.

[theamk]

He is talking about homedir encryption with auto-lock, and this fundamentally incompatible with cronjobs.

Sorry, you got to choose - cronjobs or secures encryption. No one can have both.

[erik_seaberg]

“Will the user hit ^D in time?” is some kind of movie-inspired imitation of security. If I can't trust that computer while I'm not logged in, I shouldn't trust it any more when I am. Encryption keys should be opaquely held by processes as capability tokens.

[michaelmrose]

I'm sorry this is wrong. Full disk encryption combined with locking said encryption on suspend secures a machine from trivial invasions of privacy while not in use or theft of the machine. Cron implementations and individual jobs can intelligently figure out how to handle missed jobs while the machine was off or suspended. Example doing the missed job once at some interval after resuming, doing it per runtime interval instead of per calendar interval, just doing the next scheduled interval.

Systemd has its own cron type implementation called timers and I'm sure it logically would work user jobs in at times the user is logged in, in the same way cron works around the fact that the user is sometimes suspended or off for indeterminate time frames.

In most cases it wont even have to. Most users machines have a lifecycle like this

POST 15 seconds Optional FDE passphrase entry 10 seconds Starting up 30 seconds to 2 minutes User login 10 seconds Operation some duration for hours to weeks Shutdown

The encrypted and or logged out state are transitory states on the way to the machines single owner entering credentials to access the device and the machine is only in those states 0.001% of its lifecycle.

For people worried about substantial secrets as opposed to a thief stealing their personal data it may be wise to segregate THAT data on a separate encrypted volume that is only unlocked during use so that opening up your machine to watch cat videos on Youtube doesn't expose thousands of patient records or company secrets.

Cron is only incompatible with homedir encryption if your scheme relies on time sensitive things which effect things OFF your computer happening ON your machine which is powered on frequently enough but not logged in as you sufficiently to complete the tasks it must also require data on your home dir to complete.

I say it has to be factors that effect off computer items because otherwise the task can simply be done as soon as you log in.

I say it must require data on your home dir to complete else your system can be told to do it for you.

For the small number of cases where one might imagine a shared computer might be turned on enough but logged in as other users one can imagine ignoring homedir encyption and simply using FDE with multiple passphrases for individual users. This will necessarily be less secure as all users would be constrained by permissions by able to break into other users local data. At this point we have identified the use case that is actually incompatible.

Shared computers with privileged local data with mutually untrustworthy users on which users need to regularly run tasks which require access to user data regardless of who is logged in.

The logical solution to which is a server, segregation to be provided by different virtual machines if needed.

[AstralStorm]

Not entirely true, a cronjob at user level can just ask for the password.

[theamk]

Not sure how that work? The computer just stands there, with no one around, and “please enter password for user joe” appears? Or same thing happens on a shared computer while another user is logged in - what next?

I mean, sure one can code this, but I cannot imagine many situations where it will be useful. I think if you want cronjobs, you just have to use service users.