Other root and non-root users: what the differences

Hello guys !

I write you for a strange question:

It's not clear form me the difference between these two commands:
Code:
root@maia:/ # dd /dev/da4 /mnt
generic_user@maia:/ % su dd /dev/da4 /mnt
Permission of /dev/da4 for root and generic_user follow:
Code:
root@maia:/ # ls -lag /dev/da4   -> crw-r--r--    1  root  operator  0x9e   ...........
generic_user@maia:/ % ls -lag /dev/da4    ->  crw-r-----    1 root    operator   0xe9  .......
I try to formulate the question:
Because dd(1) needs root privileges to run, generic_user is forced to use su(1). But if generic_user became root, the /dev/da4 device is no longer in a security condition. Or is this wrong?


Again: when a generic user runs a program with su(1) privileges (like: su dd....., su mount ....), the super-user privileges are need only to the program to be running, or maybe all the generic_user's account files go in a writable condition?


Please, you can tell me where I'm wrong ?

Thanks in advance.
 
It's not clear form me the difference between these two commands:
Both commands are wrong. I'm guessing you're mixing up two commands, dd(1) and mount(8).

Because dd(1) needs root privileges to run
I believe this is the cause of the confusion, dd(1) doesn't need root to run.
Code:
dice@molly:~/temp % dd if=/dev/zero of=test.file bs=1024 count=2
2+0 records in
2+0 records out
2048 bytes transferred in 0.000042 secs (49146889 bytes/sec)

If we take a command like dd if=/dev/zero of=/dev/da4 bs=1024 count=1 (I'm assuming that's the kind of command you meant), it requires root privileges because it will write to /dev/da4 and the permissions on /dev/da4 only allow root to do that. It has nothing to do with the command itself, only what you're doing with the command.

Similarly, echo 'bogus="YES"' >> /etc/rc.conf requires root because the file you're going to append (/etc/rc.conf in this case) is only writable by root. It's not the echo(1) command that needs root, it will happily append or write to files a user has permissions for.
 
In addition to SirDice's really good explanation, there is another way to look at it (it ends up giving the same answer).

The capabilities of a user depend obviously on who the user is. As the normal user "ralphbsz" on my machine at home, I can only do certain things, like write to files that are owned by myself and are set to be owner-writeable, or read all files that are world-readable, and so on. On the other hand, the root user (which is defined as any user whose numeric user ID is zero) can bypass all access permissions, and read and write any file or device they like (this statement is not actually 100% true, but close enough). Every running process (whether it is the shell you type commands in, or a program that has been started by the shell, like dd) runs as a particular user; you can find out which one that is by using the id command.

Usually, one logs in as a normal non-root user. The su (and its cousin sudo) allow running a command as a different user, for example root. So in your example above: "su dd /dev/da4 /mnt" probably wants to mean: run the command "dd ..." as if that one command had been typed by root. In reality, the way it works: The su starts a shell as the root user, and then directs the shell to execute the command.

Unfortunately, you screwed up the syntax slightly. To begin with, the first word after "su" has to be the desired user name, so you should have written "su root ...". And then, shells can only actually execute shell scripts when executed with an argument, so "su root dd" won't work at all. I think you probably meant to say "sudo" instead.
 
Hello guys,

thanks very much for your important clarifications.

So, let me pose, please, the operative questions.

I've defined a generic user following the statements in the FreeBSD Handbook, avoiding to invite generic_user into wheel grou:

# adduser
Username: generic_user
Full name: generic_user_testing
Uid (Leave empty for default):
Login group [generic_user]:
Login group is generic_user. Invite generic_user into other groups? []:
Login class [default]:
Shell (sh csh tcsh zsh nologin) [sh]: csh
Home directory [/home/jru]:
Home directory permissions (Leave empty for default):
Use password-based authentication? [yes]:
Use an empty password? (yes/no) [no]:
Use a random password? (yes/no) [no]:
Enter password:
Enter password again:
Lock out the account after creation? [no]:
Username : generic_user
Password : ****
Full Name : J. Random User
Uid : 1001
Class :
Groups : generic_user
Home : /home/generic_user
Shell : /usr/local/bin/csh
Locked : no
OK? (yes/no): yes
adduser: INFO: Successfully added (generic_user) to the user database.
Add another user? (yes/no): no
Goodbye!
#

Please, can you tell me what I need to change, to reach this goal:

1) everytime I login as generic_user and plug in a usb stick (/dev/da4):

ls -lag /dev/da4 -> cr-------- generic_user ........... (only generic_user and nobody else !)

2) dd if=/dev/da4 of=/dev/ada1p1/testing

where the /dev/ada1p1 sata hard disk has been previously writing mounted by the root user (because the mount command needs superuser privileges and the MUST is: generic_user can only read and nothing else).


Thanks in advance.

I hope to hear you soon.
 
Code:
of=/dev/ada1p1/testing
Is an error. You cannot reference files like this.
 
Ok ... I apologize with you for this error !

I write you the correct one:

dd if=/dev/da4 of=/mnt/testing/image.dd

where /mnt is the directory where the partition /dev/ada1p1 of the sata hard disk mounted by the root user (because the mount command needs superuser privileges and the MUST is: generic_user can only read and nothing else).

Excuse me again !

And now ?
 
Now would probably be a good time to look into devfs.conf(5), that's the process directly responsible for maintaining the /dev entries, and as you can see in this manual page it allows you to configure a specific uid/gid and permission bits for certain devices. I'd start there.
 
Thanks very much !

Effectively devfs.conf(5) is the right starting point to define permissions for the managing of /dev devices for any users.

Regards.
 
Back
Top