USB fat32 mounted as user on work kubuntu, but mounted as root on home kubuntu

[oshunluvr]

nothing to report after the udev rules investigation.
/etc/udev/rules.d is empty.
/etc/udev/rules.d looks normal.

here's the content of usbmount.rules...

g@bitter:/lib/udev/rules.d$ cat  usbmount.rules
# Rules for USBmount -*- conf -*-

KERNEL=="sd*", DRIVERS=="sbp2",         ACTION=="add",  RUN+="/usr/share/usbmount/usbmount add"
KERNEL=="sd*", SUBSYSTEMS=="usb",       ACTION=="add",  RUN+="/usr/share/usbmount/usbmount add"
KERNEL=="ub*", SUBSYSTEMS=="usb",       ACTION=="add",  RUN+="/usr/share/usbmount/usbmount add"
KERNEL=="sd*",                          ACTION=="remove",       RUN+="/usr/share/usbmount/usbmount remove"
KERNEL=="ub*",                          ACTION=="remove",       RUN+="/usr/share/usbmount/usbmount remove"

running out of ideas...
i will verify this hasn't to do with the usb hardware interfaces being "old" usb2.0 while these pens i'm using are all now usb3.0...

This is very interesting as neither "/usr/share/usbmount/usbmount" nor "/lib/udev/usbmount.rules" exist on my system anywhere at all.

[oshunluvr]

So you've installed "usbmount"? What's the contents of usbmount.conf?

[oshunluvr]

I see this in the default usbmount.conf

# Mount options: Options passed to the mount command with the -o flag.# See the warning above regarding removing "sync" from the options.
MOUNTOPTIONS="sync,noexec,nodev,noatime,nodiratime"


# Filesystem type specific mount options: This variable contains a space
# separated list of strings, each which the form "-fstype=TYPE,OPTIONS".
#
# If a filesystem with a type listed here is mounted, the corresponding
# options are appended to those specificed in the MOUNTOPTIONS variable.
#
# For example, "-fstype=vfat,gid=floppy,dmask=0007,fmask=0117" would add
# the options "gid=floppy,dmask=0007,fmask=0117" when a vfat filesystem
# is mounted.
FS_MOUNTOPTIONS=""

[jankushka]

thanks oshunluvr.

No offence, but "the same" means just that and our systems are not the same. The fact that yours is using a different group to mount removable devices is significant. Group 100 is accessible by any user logged into the system and mine is not. This is a rather large difference in terms of file security. The fact that you're OK with that doesn't change anything.

no offence no: don't worry.
only your point is...totally besides the point.
file security (after the filesystem is mounted) is a different topic.

what i said is:
- on "peanuts" the options used to mount the fat file system are the same as on your system (and they are, and "peanuts" works as expected)
- on "bitter" they aren't (and "bitter" doesn't work as one would expect it to work)

"bitter" doesn't apply uid/gid (whatever the value of uid/gid may be).

i know it's me who did something to the system that makes it behave as it does.
i'm not the regular user, as you might have realized, and i (must) do all sorts of bad things to my systems especially for work.
so...just to clarify: i'm not blaming kubuntu (or the forces of the world acting against me).

moving on...

Curious if these were clean installs or upgrades from previous versions? Could be something left over from a previous install. Another test; create a new user and log in as that user, then re-run the mount list after mounting the USB drive. This will show us if it's a user setting or system setting causing this.

they were clean installs.
i'm coming back to kubuntu after several years of plain ubuntu.

So you've installed "usbmount"? What's the contents of usbmount.conf?

now, this is a good point!
well spotted.

i don't remember having installed usbmount.
i can't even think of why i would have wanted to install it.
but i obviously did.

i'm at work right now and there is no usbmount installed on "peanuts".
which is...good.

i will check "bitter" at home tonight when i get back.
hope this is the issue.


thanks again.

[jankushka]

usbmount was the issue.

i removed it and everything's back to normal.
obviously it overrides default mounting rules.

g@bitter:~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
...
sdb      8:16   1    30G  0 disk 
└─sdb1   8:17   1    30G  0 part 

g@bitter:~$ udisksctl mount --block-device /dev/sdb1
Mounted /dev/sdb1 at /media/g/R2-D2.

g@bitter:/media/g$ ll
total 24
drwxr-x---+ 3 root root   4096 Apr  9 20:18 ./
drwxr-xr-x  4 root root   4096 Apr  9 20:14 ../
drwxr-xr-x  5 g    users 16384 Jan  1  1970 R2-D2/

g@bitter:/media/g$ mount
...
/dev/sdb1 on /media/g/R2-D2 type vfat (rw,nosuid,nodev,relatime,uid=1001,gid=100,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

kudos to everyone.
kudos to oshunluvr especially.

great community.

thanks.

[oshunluvr]

Great. Glad you're satisfied.

I'm still curious as to why your USB drives are being mounted to the USERS group rather than the group of the user mounting it. I've never seen that behavior so there must be something else controlling that. Are you using Automount? Could be a setting there.

As purely a security issue it's a small vector. You'd actually have to mount a USB stick, leave it mounted, have someone else log into the machine, and want to access the files on it. I suppose if it's on a local network with SSH enabled weakly it could happen. Doesn't seem very likely. Still, in a public environment it could be a danger.

[jankushka]

Great. Glad you're satisfied.

yeah.
very satisfied.
always.
after all these years i still find it amazing that there's people out there willing to help.
valuable people.
i used to do my fair share a few years back.
now, i just don't have the time anymore.

I'm still curious as to why your USB drives are being mounted to the USERS group rather than the group of the user mounting it. I've never seen that behavior so there must be something else controlling that. Are you using Automount? Could be a setting there.

oh, that's just how the users are configured when they're created.
it's no big deal.

here's the /etc/passwd:

...
f:x:1000:100:f:/home/f:/bin/bash
g:x:1001:100:g:/home/g:/bin/bash
j:x:1002:100:j:/home/j:/bin/bash
...

and /etc/group:

users:x:100:f,g,j

if you have several users on the same system having a private group for each one of them is not always ideal/practical.
sometimes you really want your users to be able to access (i.e. most of the times this means: read) each other's stuff in a simple way.
if you have wife/girlfriend, kids, etc. for example.
being all part of the same group (the fact it's called "users" is just legacy: you could call it "family" if it's a family group...) is just that.

As purely a security issue it's a small vector. You'd actually have to mount a USB stick, leave it mounted, have someone else log into the machine, and want to access the files on it. I suppose if it's on a local network with SSH enabled weakly it could happen. Doesn't seem very likely. Still, in a public environment it could be a danger.[/QUOTE]

yeah, yeah.
absolutely.
you would have to be very careful about this in a public environment.
agree!
you would have to know what you're doing.
but these systems are not accessible from outside/public nets.

plus, default umask is 0022 for everyone (that's default on unix systems since the beginning of times, i think):

g@bitter:/media/g$ umask
0022

this means only you have read/write permissions on your files and read/write/list on your directories, by default.
all others only have read on files and read/list on directories.
and it's up to you to decide what you want to open up for writing.
so, as long as it's ok with other users being able to read your files and list your directories (we're talking about family here or team mates at work), this is a very simple/practical approach.

hth.

[oshunluvr]

Ah, that explains it and actually makes sense. Occam's Razor should have led me there. The default Kubuntu setup is individual group for each user vs. assigning USERS as primary group.

I've toyed with changing my systems on my network to the same setup but got tired of it. Now I just add a group called "shared" and put those users into that group so they can access the media storage on the server. It's less work for me to mount the exports with that group and nouser rather than reconfigure each installation.

Thanks for taking time time to explain what I should have been able to figure out.

[jankushka]

cheers.