[SOLVED] How to make a group owner be a user owner of a file?

fanoflq · 03-02-2017, 05:03 PM

How to make a group owner be a user owner of a file?
Is this possible?

One can change group ownership of a
file using chown or chgrp.
Create a group using groupadd.

But is it possible to make a group name to
become a user owner of a file?
Note that this group does not have a user name
it just has a group name (obviously!).

I do not think it is possible since
user owner is for user name ONLY and
NOT for group name, but there may be
a trick to do this that I do not know yet!

Am I correct?

Jjanel · 03-02-2017, 05:36 PM

Can you explain more, about what you want to -accomplish-, and some examples of what you tried?

I got an 'interesting' result: (can a LQguru explain why sudo refused but su;chown 'worked'?)

Code:

user@darkstar:~$ sudo chown 3210 z #NO sudo in [some OLD thing called ...umm...] slackware! WTH is THAT? malware? :D
-bash: sudo: command not found
user@darkstar:~$ su -c chown 3210 z #or sudo, in M$Ubuntu etc
No passwd entry for user '3210'
user@darkstar:~$ ls -l
-rw-r--r-- 1 user users 0 Feb 27 21:00 z
user@darkstar:~$ grep user /etc/passwd /etc/group
/etc/passwd:user:x:1000:100:,,,:/home/user:/bin/bash
/etc/group:users:x:100:
user@darkstar:~$ su
root@darkstar:/home/user# chown 3210 z
root@darkstar:/home/user# ls -l
-rw-r--r-- 1 3210 users 0 Feb 27 21:00 z

p.s. Yes, I 'web-researched' (a little anyway

):
No results found for intitle:chown "No passwd entry for"

hydrurga · 03-02-2017, 05:56 PM

@Jjanel

The su -c command is treating "chown" as the command and "3210" as the user you want to run the command as.

Try enclosing the whole command in quotes e.g. su -c 'chown 3210 z'

r3sistance · 03-02-2017, 06:08 PM

A group and a user are fundamentally different, so no a group can only be the group owner of a file, not the user owner of a file.

Is there a specific issue you have here? It'll probably be something covered under SGID or Filesystem ACLs...

Jjanel · 03-02-2017, 06:11 PM

Oh! Thanks! Yup, that fixed it! **MY Noob mistake!** And sudo (of course) worked [in Ubu]:

Code:

user@ubuntu:~/dir$ ls
user@ubuntu:~/dir$ touch z
user@ubuntu:~/dir$ sudo chown 3210 z
[sudo] password for user:
user@ubuntu:~/dir$ ls -l #note: use -n switch in ls, to see NUMeric IDs!
-rw-rw-r-- 1 3210 user 0 Mar  2 15:25 z

Now, any idea what OP is trying to say?

dijetlo · 03-02-2017, 06:15 PM

Having a group id (GID) being used in place of the users ID (UID) in an ACL is not going to work

Code:

bash-4.3# getfacl -n flg.inod 
# file: flg.inod
# owner: 1001 <--UID must match a UID in /etc/password
# group: 1000 <--GID must match a GID in /etc/group
user::rw-
group::r--
other::r--

So yes, you are correct

NOTE: The names are just for our convenience (or confusion depending on your naming conventions for groups and users) only the UID/GID numbers are referenced by the system

fanoflq · 03-02-2017, 06:41 PM

Quote:

Originally Posted by r3sistance

A group and a user are fundamentally different, so no a group can only be the group owner of a file, not the user owner of a file.

Is there a specific issue you have here? It'll probably be something covered under SGID or Filesystem ACLs...

No, nothing specific.
It is just something I was wondering.
With ACL, you can only assign permission using u, g, or o.
It is still not possible to assign a group name to a user in ACL using setfacl.

Code:

#Granting a group as user for access would generate error
   setfacl -m u:some_group_name:rwx file3

r3sistance · 03-02-2017, 07:27 PM

No, even when it is acls, because how the system treats a user and a group are different. Also the system doesn't store it by names but by numerical id, the system just does a look-up on /etc/passwd to convert the uid and on /etc/group to convert the uid and the gid into names when you view them but if you looked at it how the system looks at it then it's just a normal integer field. Specifically I believe it is a 2 byte unsigned integer but not looking that up now to confirm... so there is nothing in there that allows for the system to distinguish between a user or a group. AFAIK ACLs use the same format for permissions but rather as being stored as a property of the file, they are stored else where in the meta data.

fanoflq · 03-02-2017, 08:03 PM

Quote:

Originally Posted by r3sistance

No, even when it is acls, because how the system treats a user and a group are different. Also the system doesn't store it by names but by numerical id, the system just does a look-up on /etc/passwd to convert the uid and on /etc/group to convert the uid and the gid into names when you view them but if you looked at it how the system looks at it then it's just a normal integer field. Specifically I believe it is a 2 byte unsigned integer but not looking that up now to confirm... so there is nothing in there that allows for the system to distinguish between a user or a group. AFAIK ACLs use the same format for permissions but rather as being stored as a property of the file, they are stored else where in the meta data.

I like the above underlined explanation.
What is "AFAIK ACLs"?

r3sistance · 03-02-2017, 08:05 PM

AFAIK = As Far As I Know

chrism01 · 03-02-2017, 10:57 PM

Just to be extremely clear, UIDs and GIDs are separate lists, so you can have the same UID and GID value, but it has no effect - they are still separate namespaces (although as above, its all stored in /etc/passwd, /etc/group.
If you deleted and entry there, the file/dir prev owned by the deleted user (or group), would still exist, but it would show up with the UID (or GID) number, as those values are stored in each file's metadata (see ctime).

HTH