User rights

19 respostas [Última entrada]
hack and hack
Desconectado
Joined: 04/02/2015

I often am puzzled about user rights:

I understand that there's a root user who has all rights, and is accessed with sudo.
I understand the normal user, who has limited rights.

Now, I often have problems with external hard disks.
It seems they require root password just to be able to copy files from/to the PC.
I can understand it's a security against other users. It's very annoying though. But it can delay an attacker for a few moments. So let's say I want to keep it that way.

Yet sometimes (or instead, with some hard disks, I'm not sure yet), when opening say Nautilus as root, the drive doesn't appear, and yet it appears on a non-root Nautilus. That's for an encrypted drive.
And this is the part where I'm on the verge of craziness.
Nothing is consistent. Oh, and of course, since it's not root, I'm "not authorized to perform operation".

Non-encrypted HHDs can be opened without rootjust fine (read rights), but there's no way to copy files without being root. An added problem is that on another (Debian) PC, I can't access them without being root if I recall correctly.
But to safely remove the disk, the only way that works is to open gnome-disks AS ROOT and do it that way.

It's ben a while I just try and make it work somehow each time, but I want to fix that once and for all.

I'll restate that this is not a standard Trisquel install, but a minimal install.

So another idea is the rights to read, write and execute. Am I supposed to set the

hack and hack
Desconectado
Joined: 04/02/2015

Oh, and just to add to the confusion, NOW I can access my encrypted HHD via sudoed gnome-disks, whereas 10 minutes ago I couldn't. Sure it might have been a typo onthe passphrase, right? But to make sure, I even copy/pasted it.

My install is messing with me ( •᷄⌓•᷅ )

SuperTramp83

I am a translator!

Desconectado
Joined: 10/31/2014

Not being able to access/copy to and from an external drive is anomalous behavior, one that I have never ever seen on any Debian based distribution (so far I used only Debian based distros, many though, especially when I was very fresh).
The non encrypted drive should not require admin rights to be accessed AFAIK. The encrypted one also shouldn't need sudo, but just the encryption password/phrase.

hack and hack
Desconectado
Joined: 04/02/2015

I knew it, it's haunted!
More seriously, that's useful info, thanks ;)

onpon4
Desconectado
Joined: 05/30/2012

Check what your external hard drives are formatted as. If they're formatted as something like ext which supports "owners", there could be a user ID mismatch. The best way to avoid this that I'm aware of is to use a filesystem that doesn't support assigning "owners" to files, e.g. NTFS (kind of counter-intuitive to be using a Microsoft FS, but it's the best choice I'm aware of for this particular use-case). But short of that, you can check your user ID and make it so that the "owner" indicated for all the files is your user ID.

hack and hack
Desconectado
Joined: 04/02/2015

Will do, thanks for the tip :)

I should also run an extended test : Two types of HHD,and to types of installs, carefully taking notes. Roughly, my Trisquel install seems to be the culprit, because I remember the encrypted drive working just fine on a normal Trisquel install.

The encrypted one should be ext4 since I formatted id myself.
The other ones are probably not using a GNU/Linux format (never formatted them since I got them).

I'll double check and will get the ID/owner info.

hack and hack
Desconectado
Joined: 04/02/2015

Ok first simple test :
a non-encrypted drive in ext4 which I can't safely remove (With Nautilus) on my install (not authorized to perform operation).
Yet on a normal Trisquel install, while I have to force the action since it says the drive is busy, it just works.

The disk ID is a weird format like 0x00randomchars (different from the internal disk and it's LUKS partitions),
whereas my user ID is four numbers.

But you know what, I just tested it on a Debian netinstall, it works also. It's probably a faulty install, it's probably easier to start over. Plus it's a clue that it's not a HDD issue (gotta test further though).

onpon4
Desconectado
Joined: 05/30/2012

Not "disk ID", the owner(s) of the files and directories. You'll find this out by right-clicking on a file and choosing "Properties", then going to the "Permissions" tab.

You'll also be able to use root here to change the owner, or you can more simply use the "chown" command.

hack and hack
Desconectado
Joined: 04/02/2015

Ok, I just changed ownership of the folder appearing at mount point to "me" (read & write). Still the same issue :(

I used Thunar/Nautilus opened with sudo to do so.

onpon4
Desconectado
Joined: 05/30/2012

If you're viewing it as root, "me" would be root, not you. So you need to choose your username instead. Also you should change the group to your user's group (usually the same as your username).

hack and hack
Desconectado
Joined: 04/02/2015

I did notice that, but I also tried my username (both on owner and group and in read & write) without success.
It still refuses to safely remove the drive (I still need a sudo gnome-disks to be able to do it. By the way the function is available only on a non-root Nautilus).

But at least this fixed the copy-paste issue I mentioned earlier :)

onpon4
Desconectado
Joined: 05/30/2012

> refuses to safely remove the drive

That's probably because root mounted it, which isn't normally supposed to happen. I think it can happen because of opening it with root instead of yourself. But that's a bit outside my knowledge zone I'm afraid. :(

hack and hack
Desconectado
Joined: 04/02/2015

Basically it's the equivalent of this command that fails without root : udisks --detach /dev/sdX

But thanks for the idea of maybe mounting as root or not (And for solving the copy-paste issue !)

Actually we're close :
"What version of Ubuntu are you running? Also, how did you mount the drive? If you mounted using root permissions, or when logged in as another user (as opposed to Nautilus or udisks in the current user), your user won't have permission to unmount using udisks"
https://askubuntu.com/questions/532586/what-is-the-command-line-equivalent-of-safely-remove-drive

Here's what I did to allow automount: https://trisquel.info/en/forum/mounting-hdd-or-dvd-both-thunar-and-pcmanfm-not-authorized-perform-operation#comment-91019

unix-group:plugdev? If I make plugdev available for my username, (if that's a thing), it might work?

Magic Banana

I am a member!

I am a translator!

Conectado
Joined: 07/24/2010

Aren't you in the "plugdev" group? See if it is in the output of:
$ groups
Also, you could see the mount options that were used, in the last column of:
$ mount

hack and hack
Desconectado
Joined: 04/02/2015

Unfortunately, plugdev is listed :/

About mount, I got this:(rw,nosuid,nodev,uhelper=udisks2)
It seems these options are standard.

EDIT:
Well, I can either try linking a bash script to a single key shortcut (but to allow sudo, I remember I had to modify some file available as root), or try another clean install.

jxself
Conectado
Joined: 09/13/2010

Oh, when I saw the subject of "User rights" I thought this was going to be a very different topic...

hack and hack
Desconectado
Joined: 04/02/2015

Oh right, I can see the double-meaning now.

Well, thankfully free-software takes care of what you mean.

GNUbahn
Desconectado
Joined: 02/18/2016

ditto

GNUbahn
Desconectado
Joined: 02/18/2016

I so often have experiences like this. I have never thought of the user id thing, so I'll check, though I hardly think so Most of my machines run Trisquel, which will all assign the same user ids since I set them up in the same fashion. For work I use Mint but as I recall they provide the same standard user ids (numbers)

If you reach reliable answers and/or procedures, please let us know

onpon4
Desconectado
Joined: 05/30/2012

It only takes one different UID to throw you off. :)

I prefer to use FAT where it is sufficient (i.e. you don't need to store big files), and NTFS otherwise. Much simpler.