[X2Go-Commits] [[X2Go Wiki]] page changed: doc:howto:tce
wiki-admin at x2go.org
wiki-admin at x2go.org
Fri Nov 17 11:53:44 CET 2017
A page in your DokuWiki was added or changed. Here are the details:
Date : 2017/11/17 10:53
Browser : Mozilla/5.0 (X11; Linux x86_64; rv:52.9) Gecko/20100101 Goanna/3.3 Firefox/52.9 PaleMoon/27.5.1
IP-Address : 134.3.37.90
Hostname : HSI-KBW-134-3-37-90.hsi14.kabel-badenwuerttemberg.de
Old Revision: https://wiki.x2go.org/doku.php/doc:howto:tce?rev=1510914280
New Revision: https://wiki.x2go.org/doku.php/doc:howto:tce
Edit Summary: [List of open ToDos/FIXMEs for this page] updated fuseext2 info
User : stefanbaur
@@ -1022,13 +1022,13 @@
FIXME Parsing the output of e.g. <code>udevadm info --query path /dev/sdb
/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sdb
cat /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/serial</code> allows to determine the serial number of a USB device. Those SHOULD be unique, but sadly, they aren't (and sometimes, they are missing entirely). Therefore, a USB serial number can't be used for
authentication, but it could be used for "weak" identification - so it could be used to set a default user name or a default session, or to download a particular sessions file.
- FIXME Automount script currently only understands VFAT and NTFS (and possibly hfs and iso9660?) - mounting other file systems will fail due to the uid= and uni_xlate mount options being unknown. Should be extended to support more file systems. ext* is problematic as it doesn't allow you to force an owner/group at mount. fuse's fuseext2 module might, though. Needs to be investigated further. However, it looks like fuseext2 only understands rw+, or rw,force as options, and write support is experimental.
+ FIXME Automount script currently only understands VFAT and NTFS (and possibly hfs and iso9660?) - mounting other file systems will fail due to the uid= and uni_xlate mount options being unknown. Should be extended to support more file systems. ext* is problematic as it doesn't allow you to force an
owner/group at mount. fuse's fuseext2 module might, though. Needs to be investigated further. However, it looks like fuseext2 only understands rw+, or rw,force as options, and write support is experimental. Update: fuseext2 will ignore access permissions, so chmod 600 root:root is still readable by the user that ran fuseext2. This is good for e.g. reading SSH keys from ext*-formatted USB media. Regarding write support, maybe a warning popup or a boot parameter should be added for those daring enough to enable it.
FIXME Maybe we should add symlinks to the mount points created by the automounter: Currently, we create ''/media/vendor_model_name/sdxn'' as a mount point. The idea is to allow the user to find their portable device using the vendor/model name description. However, this is unusable for scripting, as the ''//x//'' in ''sdxn'' may change any time. We should replace ''//sdx//'' with ''//partition//'' (or have corresponding symlinks created), but what should we do for
//superfloppies// that only have ''sdx'' with no partition number? We could mount them as ''/media/vendor_model_name/partition/'' or directly at ''/media/vendor_model_name/''. Also, symlinks using labels and uuids, similar to ''/dev/by-*'' would be handy for scripting. Another problem: when replacing ''sdx'', what will happen when a user inserts two media with the same vendor/model name at the same time? Blindly replacing the string would make one of them inaccessible due to overwriting the symlink(s). We'd have to start checking active mounts and enumerate them like ''media/vendor_model_name/1/partitionn/'' or ''media/vendor_model_name-1/partitionn/''.
FIXME Automount script currently expects a LUKS password in ''/etc/keys/keystick.key'' when it believes it has found an encrypted partition on USB media. This is a problem in general, as it should be trivial to sniff out this password using a rogue client. If we want to support this feature, though, we should add code to the
build script that lets the user place a password file in the image, and sets proper restrictive permissions. Adding a boot parameter instead of hardcoding it would allow for dynamic password files, but on the other hand, would make it even easier to sniff out the password.
FIXME ''x2gocdmanager'' is currently not part of the image (I think), but should probably become part of it. While optical media are on their way out, they still exist and thus we should support them.
FIXME ''pinentry-x2go'' and ''x2gosmartcardrules'' probably need further investigation to make smartcard authentication work.
--
This mail was generated by DokuWiki at
https://wiki.x2go.org/
More information about the x2go-commits
mailing list