dx-packages team mailing list archive

[Charlie Ott <charlieott@xxxxxxxxx>]

Public bug reported:

Using Ubuntu 14.04 LTSP amd64 fat client with gnome-keyring
3.10.1-1ubuntu4

When launching something like Google Chrome (Which attempts to utilize
the gnome keyring), Creating a 'new' keyring password causes the tool to
hang.  It also creates thousands of files labeled
Default.temp.keyring-#####, where the numbers seemed to be a sequence
that is being automatically generated.

when the daemon tries to create the first(new) keyring from the google
chrome initiated prompt, the files are created in the user home folder:
~/.local/share/keyrings/

There were so many temp files that I had to kill the keyring daemon
(-start -components=secret) and use 'find . -type f -delete' since the
rm command was taking too long attempting to delete so many files.  So
now I just hit 'cancel' whenever the keyring pops up.  However, I would
like to get this working for my end users.

Here is some information about how the /run folder is mounted and what
the environment variables are.  This is likely an LTSP issue, but I am
not sure what to report to the LTSP team.

cott@ltsp550:~$ mount
overlayfs on / type overlayfs (rw)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
/dev/nbd0 on /rofs type squashfs (ro,relatime)
tmpfs on /cow type tmpfs (rw,relatime,mode=755)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
server:/home/cott on /home/cott type fuse.sshfs (rw,nosuid,nodev,allow_other)
gvfsd-fuse on /run/user/59319/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=cott)

cott@ltsp550:~$ env | grep keyring
GPG_AGENT_INFO=/run/user/59319/keyring-ypJP2X/gpg:0:1
GNOME_KEYRING_CONTROL=/run/user/59319/keyring-ypJP2X
SSH_AUTH_SOCK=/run/user/59319/keyring-ypJP2X/ssh
OLDPWD=/run/user/59319/keyring-ypJP2X


I have also recently found out that LTSP thick clients do not have access to the shadow file.  Which is not an issue in my case since my users are authenticated against an external directory server using the LDAP for sssd.

** Affects: ltsp (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: keyring ltsp

** Package changed: unity (Ubuntu) => ltsp (Ubuntu)

** Description changed:

  Using Ubuntu 14.04 LTSP amd64 fat client with gnome-keyring
  3.10.1-1ubuntu4
  
  When launching something like Google Chrome (Which attempts to utilize
  the gnome keyring), Creating a 'new' keyring password causes the tool to
  hang.  It also creates thousands of files labeled
  Default.temp.keyring-#####, where the numbers seemed to be a sequence
  that is being automatically generated.
  
+ when the daemon tries to create the first(new) keyring from the google
+ chrome initiated prompt, the files are created in the user home folder:
+ ~/.local/share/keyrings/
+ 
  There were so many temp files that I had to kill the keyring daemon
  (-start -components=secret) and use 'find . -type f -delete' since the
  rm command was taking too long attempting to delete so many files.  So
  now I just hit 'cancel' whenever the keyring pops up.  However, I would
  like to get this working for my end users.
  
- 
- Here is some information about how the /run folder is mounted and what the environment variables are.  This is likely an LTSP issue, but I am not sure what to report to the LTSP team.
+ Here is some information about how the /run folder is mounted and what
+ the environment variables are.  This is likely an LTSP issue, but I am
+ not sure what to report to the LTSP team.
  
  cott@ltsp550:~$ mount
  overlayfs on / type overlayfs (rw)
  proc on /proc type proc (rw,noexec,nosuid,nodev)
  sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
  udev on /dev type devtmpfs (rw,mode=0755)
  devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
  tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
  /dev/nbd0 on /rofs type squashfs (ro,relatime)
  tmpfs on /cow type tmpfs (rw,relatime,mode=755)
  none on /sys/fs/cgroup type tmpfs (rw)
  none on /sys/fs/fuse/connections type fusectl (rw)
  none on /sys/kernel/debug type debugfs (rw)
  none on /sys/kernel/security type securityfs (rw)
  none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
  none on /run/shm type tmpfs (rw,nosuid,nodev)
  none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
  none on /sys/fs/pstore type pstore (rw)
  systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
  server:/home/cott on /home/cott type fuse.sshfs (rw,nosuid,nodev,allow_other)
  gvfsd-fuse on /run/user/59319/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=cott)
  
- 
  cott@ltsp550:~$ env | grep keyring
  GPG_AGENT_INFO=/run/user/59319/keyring-ypJP2X/gpg:0:1
  GNOME_KEYRING_CONTROL=/run/user/59319/keyring-ypJP2X
  SSH_AUTH_SOCK=/run/user/59319/keyring-ypJP2X/ssh
  OLDPWD=/run/user/59319/keyring-ypJP2X
  
  
- Also worth noting, when the daemon tries to create the keyring from the google chrome initiated prompt, the files are created in the user home folder: ~/.local/share/keyring/
- 
- I have also recently found out that LTSP thick clients do not have
- access to the shadow file.  Which is not an issue in my case since my
- users are authenticated against an external directory server using the
- LDAP for sssd.
+ I have also recently found out that LTSP thick clients do not have access to the shadow file.  Which is not an issue in my case since my users are authenticated against an external directory server using the LDAP for sssd.

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to unity in Ubuntu.
Matching subscriptions: dx-packages
https://bugs.launchpad.net/bugs/1320982

Title:
  amd64 ltsp fat client keyring daemon hangs

Status in “ltsp” package in Ubuntu:
  New

Bug description:
  Using Ubuntu 14.04 LTSP amd64 fat client with gnome-keyring
  3.10.1-1ubuntu4

  When launching something like Google Chrome (Which attempts to utilize
  the gnome keyring), Creating a 'new' keyring password causes the tool
  to hang.  It also creates thousands of files labeled
  Default.temp.keyring-#####, where the numbers seemed to be a sequence
  that is being automatically generated.

  when the daemon tries to create the first(new) keyring from the google
  chrome initiated prompt, the files are created in the user home
  folder: ~/.local/share/keyrings/

  There were so many temp files that I had to kill the keyring daemon
  (-start -components=secret) and use 'find . -type f -delete' since the
  rm command was taking too long attempting to delete so many files.  So
  now I just hit 'cancel' whenever the keyring pops up.  However, I
  would like to get this working for my end users.

  Here is some information about how the /run folder is mounted and what
  the environment variables are.  This is likely an LTSP issue, but I am
  not sure what to report to the LTSP team.

  cott@ltsp550:~$ mount
  overlayfs on / type overlayfs (rw)
  proc on /proc type proc (rw,noexec,nosuid,nodev)
  sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
  udev on /dev type devtmpfs (rw,mode=0755)
  devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
  tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
  /dev/nbd0 on /rofs type squashfs (ro,relatime)
  tmpfs on /cow type tmpfs (rw,relatime,mode=755)
  none on /sys/fs/cgroup type tmpfs (rw)
  none on /sys/fs/fuse/connections type fusectl (rw)
  none on /sys/kernel/debug type debugfs (rw)
  none on /sys/kernel/security type securityfs (rw)
  none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
  none on /run/shm type tmpfs (rw,nosuid,nodev)
  none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
  none on /sys/fs/pstore type pstore (rw)
  systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
  server:/home/cott on /home/cott type fuse.sshfs (rw,nosuid,nodev,allow_other)
  gvfsd-fuse on /run/user/59319/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=cott)

  cott@ltsp550:~$ env | grep keyring
  GPG_AGENT_INFO=/run/user/59319/keyring-ypJP2X/gpg:0:1
  GNOME_KEYRING_CONTROL=/run/user/59319/keyring-ypJP2X
  SSH_AUTH_SOCK=/run/user/59319/keyring-ypJP2X/ssh
  OLDPWD=/run/user/59319/keyring-ypJP2X

  
  I have also recently found out that LTSP thick clients do not have access to the shadow file.  Which is not an issue in my case since my users are authenticated against an external directory server using the LDAP for sssd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1320982/+subscriptions