A page in your DokuWiki was added or changed. Here are the details:
Date : 2017/11/20 12:42
Browser : Mozilla/5.0 (X11; Linux x86_64; rv:52.9) Gecko/20100101
Goanna/3.4 Firefox/52.9 PaleMoon/27.6.0
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=1511181542
New Revision: https://wiki.x2go.org/doku.php/doc:howto:tce
Edit Summary: [List of open ToDos/FIXMEs for this page] updated automounter
script FIXME
User : stefanbaur
@@ -1042,9 +1042,9 @@
/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.
Authentification and "hard" identification could be implemented using OpenPGP cards, ''scdaemon'' and a script based on
''/usr/share/doc/scdaemon/examples/scd-event''. For Status ''NOCARD'', suspend the session (kill x2goclient or send a signal that
means "suspend", if available, or maybe sighup nxproxy), for status ''USABLE'', run ''gpg --card-status 2>&1 | awk
'$1=="Serial" && $2=="number" {print $4}''' to determine the card's serial number, then act based on that
(pull new sessions file or set default user, for example, and restart x2goclient).
- 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 Automount script expansion is in the works. Will fully support VFAT,
NTFS, hfs, hpfs, will offer read-only support for ext* via fuseext2 (that way,
file ownership/permissions are ignored).
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.
--
This mail was generated by DokuWiki at
https://wiki.x2go.org/
_______________________________________________
x2go-commits mailing list
[email protected]
https://lists.x2go.org/listinfo/x2go-commits
