Re: Guest Samba shares
On 11/12/20 1:42 pm, Paul M Foster wrote: For various reasons, I've set the perms on this mount as 777. Anything on a Raspberry Pi gets mounted in the /media/pi hierarchy by default. I couldn't see a reason to change it, if I set the permissions appropriately. G'day Paul pi being the default user under raspbian/raspOS. At least with the recent installer, you are required to give pi a password. It used be that there was a default password, and you had to know to change that yourself. My 2c worth: as you have already set up a personal user, disable auto log-in to user pi and make sure user pi has a strong password. Having user pi available is likely the prime target of any attack, simply because it used have a default. Once you start logging in as paul, you'll find that automount USB item go to /media/paul. -- Keith Bainbridge ke1thozgro...@gmx.com
Re: Guest Samba shares
On 12/11/2020 5:47 AM, Paul M Foster wrote: On Thu, Dec 10, 2020 at 10:09:20PM -0500, Stefan Monnier wrote: Anything on a Raspberry Pi gets mounted in the /media/pi hierarchy by default. I'm pretty sure that it's not the case. It's a matter of the OS you run on your Pi, not the fact that it's a Raspberry Pi. IIUC what you're saying is that you're not running plain Debian but some other OS and that OS uses /media/pi by default mount things. It's important to clarify those details here, because this is a Debian mailing-list, so readers like me generally presume that you're using Debian and not some other (presumably Debian-derivative) OS. Stefan Oops. I sent the reply without the reply. Sorry. The Raspberry Pi (the server in this case) runs a variant of Debian, Raspberry Pi OS. Where the disc mounts is an incidental detail. Samba, whether on Fedora, Arch or Debian, is configured more or less the same way. Since I've been running Debian alone for the last 20 years, this seemed to be the best place to ask the question. For Samba question I would probably ask on the Samba mailing list! :) -- John Doe
Re: Guest Samba shares
On Thu, Dec 10, 2020 at 10:09:20PM -0500, Stefan Monnier wrote: > > Anything on a Raspberry Pi gets mounted in the /media/pi hierarchy > > by default. > > I'm pretty sure that it's not the case. It's a matter of the OS you run > on your Pi, not the fact that it's a Raspberry Pi. > > IIUC what you're saying is that you're not running plain Debian but some > other OS and that OS uses /media/pi by default mount things. > > It's important to clarify those details here, because this is a Debian > mailing-list, so readers like me generally presume that you're using > Debian and not some other (presumably Debian-derivative) OS. > > > Stefan > Oops. I sent the reply without the reply. Sorry. The Raspberry Pi (the server in this case) runs a variant of Debian, Raspberry Pi OS. Where the disc mounts is an incidental detail. Samba, whether on Fedora, Arch or Debian, is configured more or less the same way. Since I've been running Debian alone for the last 20 years, this seemed to be the best place to ask the question. Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com
Re: Guest Samba shares
On Thu, Dec 10, 2020 at 10:09:20PM -0500, Stefan Monnier wrote: > > Anything on a Raspberry Pi gets mounted in the /media/pi hierarchy > > by default. > > I'm pretty sure that it's not the case. It's a matter of the OS you run > on your Pi, not the fact that it's a Raspberry Pi. > > IIUC what you're saying is that you're not running plain Debian but some > other OS and that OS uses /media/pi by default mount things. > > It's important to clarify those details here, because this is a Debian > mailing-list, so readers like me generally presume that you're using > Debian and not some other (presumably Debian-derivative) OS. > > > Stefan > -- Paul M. Foster http://noferblatz.com http://quillandmouse.com
Confirm your subscription for SoulwaterProductions
Howdy. You recently signed up to follow this blog's posts. This means once you confirm below, you will receive each new post by email. To activate, click Confirm Follow. If you believe this is an error, ignore this message and nothing more will happen. Blog Name: SoulwaterProductions URL: http://soulwaterproductions.com Confirm Follow: https://subscribe.wordpress.com/?key=30364bd404ddb09c361d89176096cfa8&email=debian-user%40lists.debian.org&activate=9a9ea2ca0055bc811d9da351797e1cdd If you don't want to receive these emails any more: https://subscribe.wordpress.com/?key=30364bd404ddb09c361d89176096cfa8&email=debian-user%40lists.debian.org If you want to see all of the blogs and posts you follow on the web in one easy place, sign up for a WordPress.com account. (http://wordpress.com/signup/?ref=lof)
Re: Guest Samba shares
> Anything on a Raspberry Pi gets mounted in the /media/pi hierarchy > by default. I'm pretty sure that it's not the case. It's a matter of the OS you run on your Pi, not the fact that it's a Raspberry Pi. IIUC what you're saying is that you're not running plain Debian but some other OS and that OS uses /media/pi by default mount things. It's important to clarify those details here, because this is a Debian mailing-list, so readers like me generally presume that you're using Debian and not some other (presumably Debian-derivative) OS. Stefan
Re: Guest Samba shares
On Fri, Dec 11, 2020 at 01:25:56AM +0100, deloptes wrote: > Paul M Foster wrote: > > > Any idea why contents are not showing up, and what can be done to remedy > > this? > > could be permissions on /media/pi/music ? > > I use it here as domain controller - only dedicated users - not sure about > the guest settings, but the mount point is strange. Somewhere it > said /media is for the system to mount devices. Looks like your user 'pi' > owns the stuff. It could be I am wrong. > > Usually you debug in the smb log files. You better look inside and post > here. > For various reasons, I've set the perms on this mount as 777. Anything on a Raspberry Pi gets mounted in the /media/pi hierarchy by default. I couldn't see a reason to change it, if I set the permissions appropriately. Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com
Re: Help with install on old Mac
On 12/5/20 1:47 AM, didier gaumet wrote: Hello Disclaimer: I am not familiar with Apple (old or new) hardware There is the Debian Jessie installation manual for the powerpc architecture: https://www.debian.org/releases/jessie/powerpc/index.html.en the 3.6.1 section could explain why you have difficulties to boot from your hard disk: https://www.debian.org/releases/jessie/powerpc/ch03s06.html.en#invoking-openfirmware but the link indicated to upgrade is broken http://gnats.netbsd.org/43952 provides an updated link: wget http://download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/English-North_American/Macintosh/System/Mac_OS_X/System_Disk_Utility.smi.bin On a side note, NetBSD, FreeBSD and OpenBSD all seem to have present version of their OS for the mac powerpc architecture:, NetBSD probably being the most advanced and supported (FreeBSD: WIP): http://wiki.netbsd.org/ports/macppc/ keep us informed if you have succeeded :-) Hello Didier, Thanks for the links. I too had noticed some of the Debian links were broken. I did try a different, smaller, USB stick for the firmware, but it did not help. Plus some of the info from other pages suggested at least one partition name might be wrong. So I decided to follow your suggestion to look into the BSD systems. I chose NetBSD and have successfully installed it. But again, getting the system to boot into it is proving a challenge. Since I'm now using NetBSD, I'll be taking this conversation over to their lists. But I may ultimately retry getting Linux up on the machine. We'll see how it goes. Thanks again, Bob
Re: Guest Samba shares
Paul M Foster wrote: > Any idea why contents are not showing up, and what can be done to remedy > this? could be permissions on /media/pi/music ? I use it here as domain controller - only dedicated users - not sure about the guest settings, but the mount point is strange. Somewhere it said /media is for the system to mount devices. Looks like your user 'pi' owns the stuff. It could be I am wrong. Usually you debug in the smb log files. You better look inside and post here.
Guest Samba shares
I've got a Pi with a hard drive connected to it with music on it. I've got SSH configured so I can admin the box headless. I've got FTP configured so I can upload music. Now I'm working on Samba. My wife has a Mac which understands Samba. She can scan the LAN on the Mac and see the music share from the Pi. But she can't see any of the files on it. I'd like her to be able to download (not upload) files from it without a login. Here's my smb.conf file, condensed to show only the relevant parts: [global] security = user workgroup = mars.lan server role = standalone server obey pam restrictions = yes unix password sync = yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . pam password change = yes map to guest = bad user usershare allow guests = yes [music] comment = Music path = /media/pi/music browseable = yes read only = yes guest ok = yes guest only = yes Any idea why contents are not showing up, and what can be done to remedy this? Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com
Major testing issues
I haven't fired up my debian testing vm in a while but I did the other day and upgraded it and now whenever X starts up, the keyboard dies. Can't even switch back to a tty. Booting in multi-user.target works fine, just not graphical.target. I thought I'd try to reinstall so I downloaded the latest testing netinst iso and no matter which item I choose from the boot menu, the domU just reboots. I'm not sure how to report this as a proper bug report.
systemd (241-7~deb10u5) + tomcat9 (9.0.39-1~bpo10+1) + override.conf on a Buster 10.7
Hi, Before turning mad, any help would be welcome! On a Buster system, I have created a /etc/systemd/system/tomcat9.service.d/override.conf file to set a value for ReadWritePaths. Using a value such as /home or /src/backup/shared, tomcat9 is starting fine and using /src/scratch/shared it does not (see the error messages below). Here are the commands to check each case: systemctl daemon-reload systemctl restart tomcat9 Here are the 'ls' outputs: $ ls -ld /home /srv/backup /srv/backup/shared /srv/scratch /srv/scratch/shared drwxr-xr-x 32 root root 4096 déc. 10 14:32 /home drwxr-xr-x 9 root root 136 déc. 8 22:53 /srv/backup drwxr-xr-x 13 ligmdb ligmusers 240 juin 28 16:51 /srv/backup/shared drwxr-xr-x 5 root root66 oct. 22 13:28 /srv/scratch drwxr-xr-x 10 ligmdb ligmusers 173 juin 28 16:51 /srv/scratch/shared Here are the 'mount' for those: imgt2:/srv/data/home on /home type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=193.50.6.90,local_lock=none,addr=193.50.6.94) imgt2:/srv/data/backup2/scratch on /srv/scratch type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=193.50.6.90,local_lock=none,addr=193.50.6.94) imgt2:/srv/data/backup2 on /srv/backup type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=193.50.6.90,local_lock=none,addr=193.50.6.94) Thanks, Patrice déc. 10 21:20:02 omega systemd[1]: Reloading. déc. 10 21:20:11 omega systemd[1]: Starting Apache Tomcat 9 Web Application Server... -- Subject: L'unité (unit) tomcat9.service a commencé à démarrer -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- L'unité (unit) tomcat9.service a commencé à démarrer. déc. 10 21:20:11 omega systemd[39264]: tomcat9.service: Failed to set up mount namespacing: No such file or directory déc. 10 21:20:11 omega systemd[39264]: tomcat9.service: Failed at step NAMESPACE spawning /usr/libexec/tomcat9/tomcat-update-policy.sh: No such file or directory -- Subject: Le processus /usr/libexec/tomcat9/tomcat-update-policy.sh n'a pas pu être exécuté -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Le processus /usr/libexec/tomcat9/tomcat-update-policy.sh n'a pas pu être exécuté, et a donc échoué. -- -- Le code d'erreur renvoyé est ERRNO. déc. 10 21:20:11 omega systemd[1]: tomcat9.service: Control process exited, code=exited, status=226/NAMESPACE -- Subject: Unit process exited -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- An ExecStartPre= process belonging to unit tomcat9.service has exited. -- -- The process' exit code is 'exited' and its exit status is 226. déc. 10 21:20:11 omega systemd[1]: tomcat9.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- The unit tomcat9.service has entered the 'failed' state with result 'exit-code'. déc. 10 21:20:11 omega systemd[1]: Failed to start Apache Tomcat 9 Web Application Server. -- Subject: L'unité (unit) tomcat9.service a échoué -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- L'unité (unit) tomcat9.service a échoué, avec le résultat failed.
Re: SanDisk USB stick problem
On Thu, Dec 10, 2020 at 10:17:41AM +0200, Andrei POPESCU wrote: On Mi, 09 dec 20, 15:23:44, Celejar wrote: I'm curious about this because I can't imagine that FUSE performance is as good as native, so why would automounters pay the performance penalty of FUSE when native mounting would seem easy enough to do? The ntfs-3g developers claim there is no significant penalty. Testing their claims would be difficult though, considering the kernel driver has limited functionality. For exfat, at least, the in-kernel driver is noticeably faster. From a reasonably fast drive I can get 600-700MByte/s with the kernel driver, and 400-500MByte/s with fuse. With a slower drive I can get about 260MByte/s with kernel, 220MByte/s with fuse. Whether the difference is "significant" probably depends on how much data you're transferring and how long you're willing to wait. In the past I've seen much larger differences for actual applications. I don't know if the fuse module has gotten faster or my quick copy test above doesn't adequately reflect real world performance. YMMV.
Re: SanDisk USB stick problem
> been implemented by the components in Debian Bullseye. Does seem a > little perverse though if it should be implemented just after Linux > gains an exFAT kernel driver, a filesystem that only really exists for > interoperability between devices (i.e. those that will be removable > media). FWIW, the use of exFAT for filesystems which will basically never be disconnected is very common in Android devices. Stefan
Re: VPN ideas
On Thu, 10 Dec 2020 10:47:13 +0200 Andrei POPESCU wrote: > On Mi, 09 dec 20, 11:53:20, Celejar wrote: > > > > As to ProtonMail, as we've discussed in the past, I'm sort of tempted, > > but I'm not willing to give up standards based email, nor am I that > > interested in running their proprietary (albeit apparently GPL?) bridge > > application. > > Yes, lack of IMAP/SMTP support is definitely a hassle and the bridge > would just ad complexity. > > One thing that is difficult to replace though is their support for > encrypted communication with *non*subscribers. There's apparently Open-Xchange / OX Guard - no idea how well it works or how easy it is to set up: https://www.wired.com/2014/09/oxguard/ https://www.oxpedia.org/wiki/index.php?title=AppSuite:Open-Xchange_Installation_Guide_for_Debian_10.0 > This is already off-topic for debian-user so I'll stop here. This part of the discussion at least is certainly relevant to Debian, so I'm leaving it here. Celejar
Re: SanDisk USB stick problem
On Thu, 10 Dec 2020 10:17:41 +0200 Andrei POPESCU wrote: > On Mi, 09 dec 20, 15:23:44, Celejar wrote: > > > > I'm curious about this because I can't imagine that FUSE performance is > > as good as native, so why would automounters pay the performance > > penalty of FUSE when native mounting would seem easy enough to do? > > The ntfs-3g developers claim there is no significant penalty. Testing > their claims would be difficult though, considering the kernel driver > has limited functionality. I'm certainly not going to dispute the ntfs-3g developers, but I had had in mind these comments of Linus Torvald that I had just come across: "People who think that userspace filesystems are realistic for anything but toys are just misguided. fuse works fine if the thing being exported is some random low-use interface to a fundamentally slow device. But for something like your root filesystem? Nope. Not going to happen." https://lkml.org/lkml/2011/6/9/462 Linus sometimes exaggerates, and in any event, external USB storage devices are (generally) somewhere in between "your root filesystem" and "some random low-use ..." A quick search turns up this: https://www.usenix.org/system/files/conference/fast17/fast17-vangoor.pdf which I haven't had a chance to read. Celejar
Re: Permissions on NFS mounts
On Thu, Dec 10, 2020 at 04:48:36PM +0300, Reco wrote:
I just like to remind you the original question:
Is there a way to put an account "beyond use", in any way including su,
sudo etc,
*In any way* includes the way I've described above IMO.
So you're asking if there's a way to prevent someone from using sudo to
do something sudo has been specifically configured to do? Kind of a
weird question, IMO. If you don't want to allow someone to sudo to a
particular user then...don't configure sudo to allow them to do that.
Also worth pointing out that having a passwd entry isn't even relevant
to whether root can setuid. At some point if you've provided enough rope
then setting a bunch of artificial constraints for the sake of argument
is just a waste of time.
# id
uid=0(root) gid=0(root) groups=0(root)
# id 1234
id: ‘1234’: no such user
# python3 -c 'import os; os.setuid(1234); os.execl("/bin/bash", "bash")'
$ id
uid=1234 gid=0(root) groups=0(root)
Re: Permissions on NFS mounts
On Thu, Dec 10, 2020 at 10:42:36AM -0500, Greg Wooledge wrote: In the context of the original question, having a consistent set of local user accounts (name/UID pairs) across all of your systems in an NFS environment is useful for making sure all files have consistent ownership. Even on the systems where, say, charlie will never log in, seeing that the files in /home/charlie are owned by user "charlie" is helpful. It's practically impossible to sync everything on a modern system in the presence of dynamically allocated IDs. The best you can hope for is sync a certain *range* of IDs and by convention only use IDs in that range within NFS exports. If something outside that range happens to sneak into the export it'll look weird, but has no real effect on security. (If you're using sec=sys on an NFS mount you have no security outside of what the client chooses to implement.) Historically this could be done by being diligent in manually creating passwd entries, via yp/nis to distribute a common passwd file, or via various configuration management schemes to automate local passwd file management. In most normal (heterogenous) environments these did only manage a certain range, and trying to sync system users was simply not done because it was harder than it was worth.
Re: Permissions on NFS mounts
On Wed, Dec 09, 2020 at 03:38:21PM -0500, Paul M Foster wrote: I have two users on the client: paulf 1000 and nancyf 1001. On the server, I have two users: pi 1000 and paulf 1001. I can mount the NFS share from the server to /mnt on my client. But any files belonging to me (user 1001 on the server) look like they belong to nancy (user 1001 on the client. More importantly, if I copy files to this share from the client, they will look like they belong to pi (user 1000) on the server. Is there some way in the /etc/exports file to adjust the parameters so that files retain my ownership on the server? Traditional NFS depends on the uid/gid matching across all the systems in a tightly controlled local network. Your solution involves changing the IDs so they match. The newer model for NFS depends on cryptographic authentication (generally kerberos) of requests rather than assuming that everything is trusted and consistently configured. In this model you can have the uid/gid be random, but you need a kerberos server. It is theoretically possible to do uid mapping without the authentication component, but that's all disabled by default and I'm not sure how current any of the directions or even the code is. You'd need to set up static maps in /etc/idmapd.conf and set nfs4_disable_idmapping=0 on the nfsd module. Also make sure you're using nfs4 and not nfs3. "idmapd.conf" and "nfs4_disable_idmapping" should be good google keywords to find instructions. Depending on your use case you might also find running samba and using cifs rather than nfs works better for you. (Or not.) It has a different authentication model and interface with its own pros and cons.
Re: Permissions on NFS mounts
On Thu, Dec 10, 2020 at 03:35:50PM +, Tixy wrote: > Why would you execute sudo or su on the target machine to change to one > of these unneeded users, presumably you can do whatever mischief is > your aim by using the account you are executing su or sudo from. Or by > changing to another valid user on that machine if you are a legitimate > user and were trying to cover your tracks. If you have full sudo access, you're *already* at the top of the food chain. You can create a new user and switch to it. You can delete users. You can lock and unlock users. You can do literally everthing, because you're the superuser. Putting additional entries in the passwd file is not a security issue, unless those entries have guessable passwords, or some other means of logging in as them from a remote system, or from a different non-root user account. Additional entries in passwd are useful for *lots* of things, such as running a service as a UID that has no other access. They are not a reduction in security. Properly used, they can increase security. In the context of the original question, having a consistent set of local user accounts (name/UID pairs) across all of your systems in an NFS environment is useful for making sure all files have consistent ownership. Even on the systems where, say, charlie will never log in, seeing that the files in /home/charlie are owned by user "charlie" is helpful.
Re: Permissions on NFS mounts
On Thu 10 Dec 2020 at 16:48:36 (+0300), Reco wrote: > On Thu, Dec 10, 2020 at 03:36:47PM +0200, Andrei POPESCU wrote: > > At least on Debian sudo has to be explicitly configured to allow a > > regular user to use '-u' with another user name. We can only assume the > > admin had good reasons to that, possibly on purpose (see below). > > You're correct here, one has to explicitly allow such activity in > sudoers in Debian and just about any OS I've encountered these years > (assuming it has sudo, of course). > > I just like to remind you the original question: > > Is there a way to put an account "beyond use", in any way including su, > sudo etc, > > *In any way* includes the way I've described above IMO. The original question was almost a textbook example of the X Y problem. The opening statement says "you'll inevitably end up with situations where users are created on some of the machines only for the purpose of keeping the IDs in synch", and that's wrong. So why try to solve it. Fortunately, this statement reveals X (which would be unreported in a true textbook example). Your reminder of the "original question" just quotes part of Mark's attempted solution to problem Y, namely creating an account that's barred. The answer to the real "original question" is to avoid creating those accounts at all—then there's no need to bar them. Cheers, David.
Re: Permissions on NFS mounts
On Thu, 2020-12-10 at 16:48 +0300, Reco wrote: > On Thu, Dec 10, 2020 at 03:36:47PM +0200, Andrei POPESCU wrote: > > On Jo, 10 dec 20, 13:34:55, Reco wrote: > > > On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > > > > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > > > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU > > > > > wrote: > > > > > > passwd -l/--lock > > > > > > > > > > sudo -u /bin/bash -i > > > > > > > > > > That little trick defeats "locked" account status, an absence > > > > > of a > > > > > password and even /usr/sbin/nologin set as a default shell. > > > > > > > > With sudo access one can also unlock the account as well, so > > > > how is this > > > > relevant? > > > > > > Of course it's relevant. The whole point of sudo is to be a > > > controlled > > > privilege escalation mechanism. > > > I.e. you can grant an ordinary user A to execute a certain > > > binaries with > > > certain arguments as a different ordinary user B, *and* you do > > > not have > > > to provide an ordinary user A an access to root. > > > > At least on Debian sudo has to be explicitly configured to allow a > > regular user to use '-u' with another user name. We can only assume > > the > > admin had good reasons to that, possibly on purpose (see below). > > You're correct here, one has to explicitly allow such activity in > sudoers in Debian and just about any OS I've encountered these years > (assuming it has sudo, of course). > > I just like to remind you the original question: > > Is there a way to put an account "beyond use", in any way including > su, > sudo etc, Which, IMO, is a rather bogus question in the context that preceded that question, namely "having unneeded users on a given machine could be a security threat, at least in the sense that it provides a greater than necessary attackable surface area" Why would you execute sudo or su on the target machine to change to one of these unneeded users, presumably you can do whatever mischief is your aim by using the account you are executing su or sudo from. Or by changing to another valid user on that machine if you are a legitimate user and were trying to cover your tracks. -- Tixy
Re: Select which system to boot while rebooting
PstrfZ writes: > On the same machine I need to host three operating systems, all > debian-based. Is it possible to select which system to boot > while rebooting? (My intent is then to reboot the selected system > by sending the command via SSH) Yes, I do this a lot in a script which hibernates Debian and reboots the system to Windows. Part of this process selecting the OS to boot for the next reboot only. So for my system that command is actually grub-reboot osprober-chain-5482E5003C6F80FB The osprober string I dug out from /boot/grub/grub.cfg. The osprober string handy in that it doesn't change that often while the name of the OS sometimes does.
Re: Permissions on NFS mounts
On Thu, Dec 10, 2020 at 03:36:47PM +0200, Andrei POPESCU wrote: > On Jo, 10 dec 20, 13:34:55, Reco wrote: > > On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > > > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > > > > > > > passwd -l/--lock > > > > > > > > sudo -u /bin/bash -i > > > > > > > > That little trick defeats "locked" account status, an absence of a > > > > password and even /usr/sbin/nologin set as a default shell. > > > > > > With sudo access one can also unlock the account as well, so how is this > > > relevant? > > > > Of course it's relevant. The whole point of sudo is to be a controlled > > privilege escalation mechanism. > > I.e. you can grant an ordinary user A to execute a certain binaries with > > certain arguments as a different ordinary user B, *and* you do not have > > to provide an ordinary user A an access to root. > > At least on Debian sudo has to be explicitly configured to allow a > regular user to use '-u' with another user name. We can only assume the > admin had good reasons to that, possibly on purpose (see below). You're correct here, one has to explicitly allow such activity in sudoers in Debian and just about any OS I've encountered these years (assuming it has sudo, of course). I just like to remind you the original question: Is there a way to put an account "beyond use", in any way including su, sudo etc, *In any way* includes the way I've described above IMO. > > Also, passwd(1): > > > > -l, --lock > >Note that this does not disable the account. The user may still > > be able to login using another authentication token (e.g. an SSH key). > > To disable the account, administrators should use usermod --expiredate 1 > > (this set the account's expire date to Jan 2, 1970). Users with a > > locked password are not allowed to change their password. > > As I said, there are limitations, that may or may not be desired, e.g. > I'm using the SSH access option, because 'systemctl --user' doesn't work > via 'sudo -u' (and it's a remote system anyway). It can, it's just inconveniencely (sp?) annoying. I.e. you have to make sure that dbus-daemon is running as a target user and you have to set DBUS_SESSION_ADDRESS to a right value, and about the only way to get that right value is to look at /proc//environ. Whoever thought it's a good idea to couple systemctl and dbus deserves something really bad happening to them. Reco
Re: Permissions on NFS mounts
On Jo, 10 dec 20, 13:34:55, Reco wrote: > On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > > > > > passwd -l/--lock > > > > > > sudo -u /bin/bash -i > > > > > > That little trick defeats "locked" account status, an absence of a > > > password and even /usr/sbin/nologin set as a default shell. > > > > With sudo access one can also unlock the account as well, so how is this > > relevant? > > Of course it's relevant. The whole point of sudo is to be a controlled > privilege escalation mechanism. > I.e. you can grant an ordinary user A to execute a certain binaries with > certain arguments as a different ordinary user B, *and* you do not have > to provide an ordinary user A an access to root. At least on Debian sudo has to be explicitly configured to allow a regular user to use '-u' with another user name. We can only assume the admin had good reasons to that, possibly on purpose (see below). It's probably unpractical to consider all ways in which the admin can compromise the security of the system. > Also, passwd(1): > > -l, --lock > Note that this does not disable the account. The user may still > be able to login using another authentication token (e.g. an SSH key). > To disable the account, administrators should use usermod --expiredate 1 > (this set the account's expire date to Jan 2, 1970). Users with a > locked password are not allowed to change their password. As I said, there are limitations, that may or may not be desired, e.g. I'm using the SSH access option, because 'systemctl --user' doesn't work via 'sudo -u' (and it's a remote system anyway). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: SanDisk USB stick problem
On Thu, Dec 10, 2020 at 10:12:50AM +, Tixy wrote: > On Thu, 2020-12-10 at 10:56 +0100, to...@tuxteam.de wrote: > > I think the tencency is to mount untrusted file systems over FUSE, [...] > > due to the realisation that file system code wasn't designed with > > malicious file system images in mind (remember? the time that code > > got written, you had one hard disk firmly screwed into your beige > > box computer), and on the hope that something exploding in user > > space might be less devastating that having it explode in kernel > > space... > > I can see there is good reasoning in that, perhaps that reasoning has > been implemented by the components in Debian Bullseye. Does seem a > little perverse though if it should be implemented just after Linux > gains an exFAT kernel driver, a filesystem that only really exists for > interoperability between devices (i.e. those that will be removable > media). I'd think exFAT lands as well in libguestfs, where it can be used by FUSE. Code is, after all, code ;-) Cheers - t signature.asc Description: Digital signature
Re: SanDisk USB stick problem
On Thu, Dec 10, 2020 at 08:15:05PM +1100, David wrote: > On Thu, 10 Dec 2020 at 19:35, Joe wrote: > > On Thu, 10 Dec 2020 08:26:40 + Tixy wrote: > > > > Sorry, I don't understand what you mean by 'Linux partitions'. > > > Partitions containing Linux filesystems. That's what we are talking about, yes. > I understand a 'Linux partition' to be one that has a > partition ID = 83h as discussed here: My understanding is ye olde partition type ID numbers are basically irrelevant comments at this point. You can set them so that you see a nice human-readable type name when you run "fdisk -l" or the equivalent, but it's not actually used for anything. You could have a Linux ext4 file system on a partition that's marked as type "Microsoft basic data" or anything else.
Re: Select which system to boot while rebooting
On Thu, 10 Dec 2020 10:29:02 +0100 (GMT+01:00) PstrfZ wrote: > On the same machine I need to host three operating systems, all > debian-based. Is it possible to select which system to boot > while rebooting? (My intent is then to reboot the selected system > by sending the command via SSH) > In addition to the other replies about grub, if your machine uses UEFI booting, the efibootmgr utility can set the next boot OS, and on some machines (e.g. not my Acer netbook) can set the default boot OS. -- Joe
Re: Permissions on NFS mounts
On 10/12/2020 09:10, Mark Fletcher wrote: > On Wed, Dec 09, 2020 at 03:54:10PM -0500, Dan Ritter wrote: >> Paul M Foster wrote: >>> I have two users on the client: paulf 1000 and nancyf 1001. On the >>> server, I have two users: pi 1000 and paulf 1001. I can mount the NFS >>> share from the server to /mnt on my client. But any files belonging to >>> me (user 1001 on the server) look like they belong to nancy (user 1001 >>> on the client. More importantly, if I copy files to this share from the >>> client, they will look like they belong to pi (user 1000) on the server. >>> >>> Is there some way in the /etc/exports file to adjust the parameters so >>> that files retain my ownership on the server? >> You're looking for userid mapping, handled by idmapd. >> >> Your best long-term solution is to make the userids consistent >> across machines by making a decision about who will be 1000, >> 1001 and 1002, and then changing /etc/passwd and running >> suitable "chown -R" commands, probably followed by find >> commands. >> >> Debian automatically starts user numbering at 1000, so it's a >> good idea to have a consistent install username, if you can >> arrange it. >> > > This brings up an interesting thought. In the situation where you align > user IDs across a number of machines for ths purpose, you'll inevitably > end up with situations where users are created on some of the machines > only for the purpose of keeping the IDs in synch so they can all play > nice with the NFS. Left alone, having unneeded users on a given machine > could be a security threat, at least in the sense that it provides a > greater than necessary attackable surface area. What can be done about > that? Obviously one thing would be setting the shell to /dev/null in the > password file of those machines that don't need a given user, to prevent > interactive logins. What else could be done? Is there a way to put an > account "beyond use", in any way including su, sudo etc, while still > having the machine recognise the user for being a user and therefore not > messing up the mapping of user IDs on shared resources like NFS? In > other words, create the sense of "yes this user exists, but they are not > welcome here"? If you're getting to the stage of managing multiple users over multiple machines, then you probably want to look at a central identity management solution. That could be as simple as NIS, or OpenLDAP or if you things a bit more "boxed up", FreeIPA. I have several computers (a mixture of physical and virtual) at home and just two humans, but FreeIPA allows us to define our users once (username/password/etc) and have that user able to log onto any FreeIPA-joined PC. Users can be added to groups, they can even be granted permissions using the RBAC and HBAC capabilities of FreeIPA (Role- and Host-base Access Control). OpenPGP_signature Description: OpenPGP digital signature
Re: Select which system to boot while rebooting
Le jeudi 10 décembre 2020 à 10:50:06 UTC+1, PstrfZ a écrit : > On the same machine I need to host three operating systems, all > debian-based. Is it possible to select which system to boot > while rebooting? (My intent is then to reboot the selected system > by sending the command via SSH) Hello, look at the grub-reboot comand
Re: Select which system to boot while rebooting
Hi. On Thu, Dec 10, 2020 at 01:46:18PM +0300, Reco wrote: > On Thu, Dec 10, 2020 at 11:12:37AM +0100, to...@tuxteam.de wrote: > > On Thu, Dec 10, 2020 at 12:00:20PM +0200, Andrei POPESCU wrote: > > > > [...] > > > > > 2. As far as I recall grub1 has a 'grub set-default' or similar command > > > that could be used for to change the default for the next boot only[b]. > > > Maybe this was re-implemented also in grub2? > > > > It seems so (note version 2.02+... at man page's footer). Since it's > > short and sweet, I take the liberty to include its man page here, as > > a special broadcast service :-) > > > > > > GRUB-SET-DEFAULT(8) System Administration Utilities GRUB-SET-DEFAULT(8) > > Please note that it's required to supply GRUB_DISABLE_SUBMENU=true > option before using grub-set-default, Debian supports it, but does not > use it by default. > Things get really weird with grub-set-default unless you use > GRUB_DISABLE_SUBMENU=true. A correction - GRUB_DISABLE_SUBMENU=true should be put into /etc/default/grub. Reco
Re: Select which system to boot while rebooting
Hi. On Thu, Dec 10, 2020 at 11:12:37AM +0100, to...@tuxteam.de wrote: > On Thu, Dec 10, 2020 at 12:00:20PM +0200, Andrei POPESCU wrote: > > [...] > > > 2. As far as I recall grub1 has a 'grub set-default' or similar command > > that could be used for to change the default for the next boot only[b]. > > Maybe this was re-implemented also in grub2? > > It seems so (note version 2.02+... at man page's footer). Since it's > short and sweet, I take the liberty to include its man page here, as > a special broadcast service :-) > > > GRUB-SET-DEFAULT(8) System Administration Utilities GRUB-SET-DEFAULT(8) Please note that it's required to supply GRUB_DISABLE_SUBMENU=true option before using grub-set-default, Debian supports it, but does not use it by default. Things get really weird with grub-set-default unless you use GRUB_DISABLE_SUBMENU=true. Reco
Re: Permissions on NFS mounts
On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > > > passwd -l/--lock > > > > sudo -u /bin/bash -i > > > > That little trick defeats "locked" account status, an absence of a > > password and even /usr/sbin/nologin set as a default shell. > > With sudo access one can also unlock the account as well, so how is this > relevant? Of course it's relevant. The whole point of sudo is to be a controlled privilege escalation mechanism. I.e. you can grant an ordinary user A to execute a certain binaries with certain arguments as a different ordinary user B, *and* you do not have to provide an ordinary user A an access to root. Also, passwd(1): -l, --lock Note that this does not disable the account. The user may still be able to login using another authentication token (e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's expire date to Jan 2, 1970). Users with a locked password are not allowed to change their password. Reco
Re: running microsoft team on debian 10.3
On 9/12/20 3:26 pm, Stefan Monnier wrote: https://askubuntu.com/questions/889164/use-phone-as-microphone-in-linux This looks interesting, indeed (tho Plumble is not maintained any more AFAICT, you might be able to use Mumla instead, also available from F-Droid). https://www.bytesin.com/how-to-use-your-phone-as-a-webcam-on-windows-linux-and-macos/ AFAICT these are all proprietary software, so I wouldn't recommend them. Stefan Thanks Stefan for the update Hoping I'm not duplicating - but better than not saying thanks, huh. -- Keith Bainbridge ke1thozgro...@gmx.com
Re: SanDisk USB stick problem
On Thu, 2020-12-10 at 10:56 +0100, to...@tuxteam.de wrote: > On Thu, Dec 10, 2020 at 09:00:39AM +, Tixy wrote: > > On Thu, 2020-12-10 at 08:53 +, Tixy wrote: > > > Perhaps your USB stick is formatted with exFAT (which only gained > > > kernel support this year) and me and Celejar are using older > > > FAT/VFAT/FAT32 (I am). That would explain our different > > > experiences > > > with fuse getting involved. > > > > I just saw from you other replies that you're on Debian unstable, > > so > > your kernel does have exFAT support. There must be something more > > complicated going on then for your system to chose to use fuse to > > mount > > the USB stick. > > I think the tencency is to mount untrusted file systems over FUSE, > due to the realisation that file system code wasn't designed with > malicious file system images in mind (remember? the time that code > got written, you had one hard disk firmly screwed into your beige > box computer), and on the hope that something exploding in user > space might be less devastating that having it explode in kernel > space... I can see there is good reasoning in that, perhaps that reasoning has been implemented by the components in Debian Bullseye. Does seem a little perverse though if it should be implemented just after Linux gains an exFAT kernel driver, a filesystem that only really exists for interoperability between devices (i.e. those that will be removable media). -- Tixy
Re: Select which system to boot while rebooting
On Thu, Dec 10, 2020 at 12:00:20PM +0200, Andrei POPESCU wrote: [...] > 2. As far as I recall grub1 has a 'grub set-default' or similar command > that could be used for to change the default for the next boot only[b]. > Maybe this was re-implemented also in grub2? It seems so (note version 2.02+... at man page's footer). Since it's short and sweet, I take the liberty to include its man page here, as a special broadcast service :-) GRUB-SET-DEFAULT(8) System Administration Utilities GRUB-SET-DEFAULT(8) NAME grub-set-default - set the saved default boot entry for GRUB SYNOPSIS grub-set-default [OPTION] MENU_ENTRY DESCRIPTION Set the default boot menu entry for GRUB. This requires setting GRUB_DEFAULT=saved in /etc/default/grub. -h, --help print this message and exit -V, --version print the version information and exit --boot-directory=DIR expect GRUB images under the directory DIR/grub instead of the /boot/grub directory MENU_ENTRY is a number, a menu item title or a menu item identifier. REPORTING BUGS Report bugs to . SEE ALSO grub-reboot(8), grub-editenv(1) The full documentation for grub-set-default is maintained as a Texinfo manual. If the info and grub-set-default programs are properly installed at your site, the command info grub-set-default should give you access to the complete manual. grub-set-default (GRUB) 2.02+dfsg1-20+deb10u2 July 2020 GRUB-SET-DEFAULT(8) signature.asc Description: Digital signature
Re: Permissions on NFS mounts
On Jo, 10 dec 20, 12:52:56, Reco wrote: > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > passwd -l/--lock > > sudo -u /bin/bash -i > > That little trick defeats "locked" account status, an absence of a > password and even /usr/sbin/nologin set as a default shell. With sudo access one can also unlock the account as well, so how is this relevant? As I already hinted, the 'locked' status has another limitation that may or may not be desired, depending on use case. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Select which system to boot while rebooting
On Jo, 10 dec 20, 10:29:02, PstrfZ wrote: > On the same machine I need to host three operating systems, all > debian-based. Is it possible to select which system to boot > while rebooting? (My intent is then to reboot the selected system > by sending the command via SSH) 1. Change the default in /boot/grub/grup.cfg[a] before rebooting. 2. As far as I recall grub1 has a 'grub set-default' or similar command that could be used for to change the default for the next boot only[b]. Maybe this was re-implemented also in grub2? [a] path and filename is from memory, it's been a while since using grub2 [b] useful in combination with a cron script to reboot the system after some delay, e.g. if one messed up the network configuration for a remote system. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: SanDisk USB stick problem
On Thu, Dec 10, 2020 at 09:00:39AM +, Tixy wrote: > On Thu, 2020-12-10 at 08:53 +, Tixy wrote: > > Perhaps your USB stick is formatted with exFAT (which only gained > > kernel support this year) and me and Celejar are using older > > FAT/VFAT/FAT32 (I am). That would explain our different experiences > > with fuse getting involved. > > I just saw from you other replies that you're on Debian unstable, so > your kernel does have exFAT support. There must be something more > complicated going on then for your system to chose to use fuse to mount > the USB stick. I think the tencency is to mount untrusted file systems over FUSE, due to the realisation that file system code wasn't designed with malicious file system images in mind (remember? the time that code got written, you had one hard disk firmly screwed into your beige box computer), and on the hope that something exploding in user space might be less devastating that having it explode in kernel space... For a rough impression, cf. e.g. here [1] It's a timid first step to remove one of those skeletons from beneath the bed (or a move towards a microkernel, depending on your current mood ;-) Cheers [1] https://lwn.net/ml/linux-kernel/20180523234114.ga3...@thunk.org/ - t signature.asc Description: Digital signature
Re: Permissions on NFS mounts
Hi. On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > Left alone, having unneeded users on a given machine could be a > > security threat, at least in the sense that it provides a greater than > > necessary attackable surface area. What can be done about that? > > Obviously one thing would be setting the shell to /dev/null in the > > password file of those machines that don't need a given user, to > > prevent interactive logins. What else could be done? Is there a way to > > put an account "beyond use", in any way including su, sudo etc, while > > still having the machine recognise the user for being a user and > > therefore not messing up the mapping of user IDs on shared resources > > like NFS? In other words, create the sense of "yes this user exists, > > but they are not welcome here"? > > passwd -l/--lock sudo -u /bin/bash -i That little trick defeats "locked" account status, an absence of a password and even /usr/sbin/nologin set as a default shell. Reco
Re: Permissions on NFS mounts
Hi. On Thu, Dec 10, 2020 at 09:10:42AM +, Mark Fletcher wrote: > This brings up an interesting thought. In the situation where you align > user IDs across a number of machines for ths purpose, you'll inevitably > end up with situations where users are created on some of the machines > only for the purpose of keeping the IDs in synch so they can all play > nice with the NFS. But why? useradd has "-u" flag for ages, all that's required is to supply an appropriate number for uid. You just create user(s) which are supposed to be on this host with the needed uid (maybe - gids), and do not create those you don't need. > Left alone, having unneeded users on a given machine > could be a security threat, at least in the sense that it provides a > greater than necessary attackable surface area. What can be done about > that? Obviously one thing would be setting the shell to /dev/null in the > password file of those machines that don't need a given user, to prevent > interactive logins. Current fashion is to use /usr/sbin/nologin for such accounts. But that's solving the problem one should not have in the first place. As for sudo and others - there's only proper one solution for such "unwelcome" users, and it's called userdel. Reco
Select which system to boot while rebooting
On the same machine I need to host three operating systems, all debian-based. Is it possible to select which system to boot while rebooting? (My intent is then to reboot the selected system by sending the command via SSH)
Re: Permissions on NFS mounts
On Jo, 10 dec 20, 09:10:42, Mark Fletcher wrote: > > This brings up an interesting thought. In the situation where you align > user IDs across a number of machines for ths purpose, you'll inevitably > end up with situations where users are created on some of the machines > only for the purpose of keeping the IDs in synch so they can all play > nice with the NFS. adduser --uid 1234 As far as I know the user creation step can be skipped in the Debian Installer, if for any reason uid 1000 is to remain unallocated, otherwise just use debootstrap/mmdebstrap instead. > Left alone, having unneeded users on a given machine could be a > security threat, at least in the sense that it provides a greater than > necessary attackable surface area. What can be done about that? > Obviously one thing would be setting the shell to /dev/null in the > password file of those machines that don't need a given user, to > prevent interactive logins. What else could be done? Is there a way to > put an account "beyond use", in any way including su, sudo etc, while > still having the machine recognise the user for being a user and > therefore not messing up the mapping of user IDs on shared resources > like NFS? In other words, create the sense of "yes this user exists, > but they are not welcome here"? passwd -l/--lock See 'man passwd' for details, limitations and alternatives. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Ipv6, but no Ipv4 after reboot
On Jo, 10 dec 20, 11:26:59, Andrei POPESCU wrote: > On Mi, 09 dec 20, 19:01:55, Dominique Dumont wrote: > > > > After boot, NetworkManager lists 2 eno2 interface: > > - one created at boot time with Ipv6 and no DNS (even though > > /etc/resolv.conf > > contains the dns entries given by dhcp) > > - one configured before which requires Ipv4 > > There can only be one 'eno2' network interface and that is handled by > the kernel and udev. > > What you are seeing is two Network Manager "connections" (as in > configurations) one with 'connection.interface-name: eno2' and one with > 'connection.interface-name: --'. > > This could be the source of your problems. My suggestion would be to > delete both connections, and create a new one from scratch. More in detail, at start Network Manager is using one connection and on reconnect the other (compare the 'connection.uuid'). Also, only one of the connections has 'connection.autoconnect: yes' (the one without interface name). > You might want to use some other name for it than 'eno2', e.g. > something like 'wired' or 'home'. > > This will prevent any confusion with the interface name (what if it > changes?) and it's also easier to distinguish between different > configurations, e.g. in case you ever need to have a 'work' connection > or so with different settings. And make troubleshooting easier :) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Ipv6, but no Ipv4 after reboot
On Mi, 09 dec 20, 19:01:55, Dominique Dumont wrote: > > After boot, NetworkManager lists 2 eno2 interface: > - one created at boot time with Ipv6 and no DNS (even though /etc/resolv.conf > contains the dns entries given by dhcp) > - one configured before which requires Ipv4 There can only be one 'eno2' network interface and that is handled by the kernel and udev. What you are seeing is two Network Manager "connections" (as in configurations) one with 'connection.interface-name: eno2' and one with 'connection.interface-name: --'. This could be the source of your problems. My suggestion would be to delete both connections, and create a new one from scratch. You might want to use some other name for it than 'eno2', e.g. something like 'wired' or 'home'. This will prevent any confusion with the interface name (what if it changes?) and it's also easier to distinguish between different configurations, e.g. in case you ever need to have a 'work' connection or so with different settings. Hope this helps, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: SanDisk USB stick problem
On Thu, 10 Dec 2020 at 19:35, Joe wrote: > On Thu, 10 Dec 2020 08:26:40 + Tixy wrote: > > Sorry, I don't understand what you mean by 'Linux partitions'. > Partitions containing Linux filesystems. I understand a 'Linux partition' to be one that has a partition ID = 83h as discussed here: https://en.wikipedia.org/wiki/Partition_type#PID_83h
Re: Permissions on NFS mounts
On Wed, Dec 09, 2020 at 03:54:10PM -0500, Dan Ritter wrote: > Paul M Foster wrote: > > I have two users on the client: paulf 1000 and nancyf 1001. On the > > server, I have two users: pi 1000 and paulf 1001. I can mount the NFS > > share from the server to /mnt on my client. But any files belonging to > > me (user 1001 on the server) look like they belong to nancy (user 1001 > > on the client. More importantly, if I copy files to this share from the > > client, they will look like they belong to pi (user 1000) on the server. > > > > Is there some way in the /etc/exports file to adjust the parameters so > > that files retain my ownership on the server? > > You're looking for userid mapping, handled by idmapd. > > Your best long-term solution is to make the userids consistent > across machines by making a decision about who will be 1000, > 1001 and 1002, and then changing /etc/passwd and running > suitable "chown -R" commands, probably followed by find > commands. > > Debian automatically starts user numbering at 1000, so it's a > good idea to have a consistent install username, if you can > arrange it. > This brings up an interesting thought. In the situation where you align user IDs across a number of machines for ths purpose, you'll inevitably end up with situations where users are created on some of the machines only for the purpose of keeping the IDs in synch so they can all play nice with the NFS. Left alone, having unneeded users on a given machine could be a security threat, at least in the sense that it provides a greater than necessary attackable surface area. What can be done about that? Obviously one thing would be setting the shell to /dev/null in the password file of those machines that don't need a given user, to prevent interactive logins. What else could be done? Is there a way to put an account "beyond use", in any way including su, sudo etc, while still having the machine recognise the user for being a user and therefore not messing up the mapping of user IDs on shared resources like NFS? In other words, create the sense of "yes this user exists, but they are not welcome here"? Mark
Re: SanDisk USB stick problem [solved]
On Mi, 09 dec 20, 19:47:14, Joe wrote: > > I believe a mount point will always be owned by root, regardless of the > permissions of the underlying directory, Nitpick: in the relevant documentation a "mount point" is the underlying directory. You're probably referring to the filesystem's root directory. Its permissions are managed the same as any other directory for "native" filesystems (ext*, xfs, etc.) and via mount options for FAT and NTFS. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: SanDisk USB stick problem
On Thu, 2020-12-10 at 08:53 +, Tixy wrote: > Perhaps your USB stick is formatted with exFAT (which only gained > kernel support this year) and me and Celejar are using older > FAT/VFAT/FAT32 (I am). That would explain our different experiences > with fuse getting involved. I just saw from you other replies that you're on Debian unstable, so your kernel does have exFAT support. There must be something more complicated going on then for your system to chose to use fuse to mount the USB stick. -- Tixy
Re: SanDisk USB stick problem
On Thu, 2020-12-10 at 08:35 +, Joe wrote: > On Thu, 10 Dec 2020 08:26:40 + > Tixy wrote: > > > > Sorry, I don't understand what you mean by 'Linux partitions'. > > Partitions containing Linux filesystems. OK, I guess you really meant filesystems supported by the Linux kernel, because we're all talking about FAT here which certainly isn't a Linux filesystems ;-) Perhaps your USB stick is formatted with exFAT (which only gained kernel support this year) and me and Celejar are using older FAT/VFAT/FAT32 (I am). That would explain our different experiences with fuse getting involved. -- Tixy
Re: VPN ideas
On Mi, 09 dec 20, 11:53:20, Celejar wrote: > > As to ProtonMail, as we've discussed in the past, I'm sort of tempted, > but I'm not willing to give up standards based email, nor am I that > interested in running their proprietary (albeit apparently GPL?) bridge > application. Yes, lack of IMAP/SMTP support is definitely a hassle and the bridge would just ad complexity. One thing that is difficult to replace though is their support for encrypted communication with *non*subscribers. > > I still have my contacts on Gmail, because of the convenient integration > > with Android, though I'd like to migrate those away as well at some > > point. And some of my calendar, will migrate that to ProtonMail as well, as soon as the (limited) free calendar is available (currently still in beta and only for paying customers). For the avoidance of doubt, I'm not affiliated with ProtonMail in any way, I'm just quite happy with their free services and their stance on privacy and freedom (including free software). > At this point, I pretty much use Gmail only for public list traffic > (although my other email accounts are also with (other) free services). > I keep thinging I really should go with either one of the inexpensive, > dedicated email providers (like Newsguy that John Hasler > often recommends) or a self-hosting solution (but I'm scared of the > apparently enormous hassle necessary to ensure reliable delivery, etc.). Similar thoughts here, though I'm rather interested in Kolab Now. This is already off-topic for debian-user so I'll stop here. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: SanDisk USB stick problem
On Thu, 10 Dec 2020 08:26:40 + Tixy wrote: > > Sorry, I don't understand what you mean by 'Linux partitions'. Partitions containing Linux filesystems. -- Joe
Re: SanDisk USB stick problem
On Wed, 2020-12-09 at 20:34 +, Joe wrote: > On Wed, 9 Dec 2020 15:23:44 -0500 > Celejar wrote: > [...] > > Interesting. I haven't been using automounting, but I just enabled > > Xfce's native automounting (Thunar / Edit / Preferences / Advanced > > / > > Volume Management:Configure / Mount removable drives when hot- > > plugged) > > and stuck in a flash drive. It gets mounted and I don't see any > > FUSE > > involved: > > > > ~$ mount | grep sdb > > /dev/sdb on /media//disk type vfat > > (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,c > > odepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,err > > ors=remount-ro,uhelper=udisks2) > > > > ~$ mount | grep fuse > > fusectl on /sys/fs/fuse/connections type fusectl > > (rw,nosuid,nodev,noexec,relatime) portal on /run/user/1000/doc type > > fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) > > > > I'm curious about this because I can't imagine that FUSE > > performance > > is as good as native, so why would automounters pay the performance > > penalty of FUSE when native mounting would seem easy enough to do? > > > > With a quick trial, it depends on the filesystem. Many of my USB > sticks > are FAT for portability, but they get mounted as fuseblk rather than > fat or vfat. How are you mounting them? On Buster with LXDE desktop, USB sticks with FAT filesystems don't get mounted by the GUI using fuse. I.e. my experience matches Celejar's. > Linux partitions are indeed mounted natively. Sorry, I don't understand what you mean by 'Linux partitions'. The only two partitioning schemes I'm aware of are MBR and GPT neither of which are Linux specific. And I can't see how the partitioning scheme would affect how a FAT filesystem is mounted. -- Tixy
Re: SanDisk USB stick problem
On Mi, 09 dec 20, 19:10:42, Joe wrote: > > I haven't investigated it thoroughly, but when I have casually checked > what is mounted, I see that any USB sticks plugged in are on fuse. Xfce > on sid, no usbmount, automounting done by systemd, by the way. That is likely to happen for NTFS, because the kernel driver has no (or very limited?) write support. For other filesystems the burden of proof is on you :) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: SanDisk USB stick problem
On Mi, 09 dec 20, 15:23:44, Celejar wrote: > > I'm curious about this because I can't imagine that FUSE performance is > as good as native, so why would automounters pay the performance > penalty of FUSE when native mounting would seem easy enough to do? The ntfs-3g developers claim there is no significant penalty. Testing their claims would be difficult though, considering the kernel driver has limited functionality. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: VPN ideas
On Mi, 09 dec 20, 19:06:27, Joe wrote: > > It's not more secure, (apart from using wifi only occasionally) but the > kind of people looking at other peoples' network activities are more > likely to target public wifi than to sit outside my house. It will > require significantly more resources and risk to tap into an ISP cable > than to sit in a cafe somewhere with a laptop (running Linux) and some > black hat software. Apparently you are assuming that in order to compromise your internet connection (spy, subvert, etc.) one has to physically tap into the cable between the ISP and your premises. As far as I understand (from my limited knowledge of networking and security) this would indeed make some (class of) attacks easier, but is *not* a strict requirement. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
