Mailinglist Archive: opensuse-bugs (16655 mails)

[bugzilla_noreply@xxxxxxxxxx]

https://bugzilla.novell.com/show_bug.cgi?id=442524

User suse-beta@xxxxxxxxx added comment
https://bugzilla.novell.com/show_bug.cgi?id=442524#c253

           Summary: broken by design: public directory support for encrypted
                    home directories (Feature No: 301923)
           Product: openSUSE 11.1
           Version: Beta4
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: Security
        AssignedTo: security-team@xxxxxxx
        ReportedBy: suse-beta@xxxxxxxxx
         QAContact: qa@xxxxxxx
          Found By: Beta-Customer


> From http://en.opensuse.org/Testing:Features_11.1

   Public directory support for encrypted home directories (Feature No: 301923)

   There are many directories such as ~/.vacation, ~/.procmail, ~/.forward, 
   ~/public_html and especially ~/.ssh that are not able to be accessed when 
   the user's home directory is encrypted as per fate #253 and the user is not 
   logged in. We should have a solution that allows these directories to be 
   made accessible when the user is not logged in.

The way this is "solved" is:
- the home directory image is mounted when the user logs in
- it is NOT umounted at logout

While this might have been the easiest solution, it has lots of disadvantages:
- all user data stays accessable, at least for root
- it is not "expected behaviour" - usually I assume that everything I open at
  login will be closed after logout
- the to-be-public data is not available until the user logs in. This might 
  take some time on machines with lots of users ;-)
- special case: ~/.ssh - if the user wants to log in over SSH using an SSH 
  key, he'll hit the typical chicken-egg problem because authorized_keys is not 
  yet available

I'm sorry to say that, but I would call this "broken by design"[tm]

Better solutions might be:
- use some symlinks to have the public files and directories on an unencrypted 
  partition
- use some overlay filesystem, again have the public files unencrypted

The decision which files have to be stored unencrypted should be on a file
basis - for example, ~/.ssh/authorized_keys should always be available, but
~/.ssh/id_dsa (the SSH private key) should not.


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.