Setting write permission for particular user

Hi All,

We have a scenario in production where we want only one user from a group to modify the file. The file is not set to write permission for application manager.

-r--r--r-- 1 amgr u00 15661716 Aug 30 00:06 DCI.dat

So here amgr will have permission to edit the file. We want a "ftpuser1" to get write permission for the file also we dont want the user "ftpuser1" to elivate the permission to amgr .

I see by setting SUID we can set that. What I read is it will make all user that are in group where "ftpuser1" is on will get the write permission

I'm not sure I fully understand, esp. if ftpuser1 is a user or a group, so a few comments here:

  • I don't see amgr permitted to edit the file - would need write permission as well.
  • SUID won't modify any permissions on a data file (which I conclude from the "extension"), but will modify the UID of the process running a command (for every user running it) so it might access files with the user's ( amgr 's) ID.
  • assigning ftpuser1 to group u00 might help given not too many users are in the u00 group and group access will be extended.
1 Like

ftpuser1 is a user. Below is the directory where the file is in. The directory has all permission to amgr believe that is the reason amgr has write permission

drwxr-xr-x 2 amgr u00 16384 Sep  6 14:47 reference

ftpuser1 cannot be added to u00 group as u00 is having the read permission. We need ftpuser1 to have write permission

You could make the file belong to ftpuser1 perhaps.

You mean to make the file owner as the ftpuser1 . As per our configuration manager structure they want all the files to owned by amgr . ALso ftpuser1 cannot be added to amgr

Phew! I've read this many times and I'm not sure that I understand either. Anyway,

Is there a reason why you can't create a separate group for write access users and set the file group setting to that group with rights ='rw'
So the file has group <newgroup> with 'rw' rights. ftpuser1 is also in group <newgroup> so gets 'rw' rights to the file.
(Remember that a user can be a member of more than one group.)

Unless you're worried about who can read the file you can give the world read rights. World='r'.

Therefore, ftpuser1 is (perhaps) the only member of a new group which can read/write the file (modify).

If you want a user to be able to write (and I mean create the file) then they'll need write access to the directory above (and there are various ways you can do that too).

Perhaps you need to explain things to us all a bit more.

2 Likes

It's getting complicated because we don't know what other users you have.

The suggestion from hicksd8 to have a new group is a good one.

How does the file arrive? If it is created by amgr, then amgr would also need to be in the group. A simple chgrp newgroup DCI.dat should then suffice. The account amgr already has write permission so that should not be an issue. Name your new group something sensible so you know what it is for and don't abuse it.

An alternate may be to use Access Control Lists (ACLs) but they are OS dependant and may not be recovered if you restore a file. What OS and version are you using? If the suggestion above does not help, I@m sure we can work something out.

Kind regards,
Robin

2 Likes

I asked our configuration team to add group they are not letting me do that. They dont want to create a new group. The user files right now sent by ftpuser1 land on one place. From where the amgr trasfer to the directory.

Now we are tying to automate the process. so that ftpuser1 can directly send the file to that directory without amgr involvement. Basically we are planning to provide a script to ftpuser1 and ask them to execute which will take the file from the path and transfer it to directory without amgr involvement. With the current permission we are getting permission errror as ftpuser1 dont have write permission.

Note: I am not sure if there a feasible solution to do without creating group or giving permission on the file/directory using a SUID

For ftpuser1 to create, delete or replace a file, it will need write access to the directory. Even if you have no permissions on the file you can then remove the file and create your own unless the directory has the sticky bit set. Can you do ls -ld /path/to/directory and have a look at the permissions? There are the usual bits for user, group & other but if the last bit it s t then the sticky bit is set. In this case, you can only remove your own files. Mainly used in /tmp so you don't dispose of other peoples' temporary files, it can have uses elsewhere too.

Can you paste the output into the thread?

Regards,
Robin

Please find the output

ls -ld /us/rep/reference
drwxr-xr-x 2 amgr  u00  4096 Sep  6 14:48 /us/rep/ref/reference

Is ftpuser1 a member of the u00 group? Is anyone else? If yes then no, you might get away with:

chmod 775 /us/rep/ref/reference

Alternatively, would you consider:

setfacl -m u:ftpuser1:rw /us/rep/ref/reference/DCI.dat

Of course, this assumes you are on RHEL or similar (which you haven't told us yet) It may fail completely if not. If this is the case, please post the output from uname -a so we know what we're dealing with.

If the setfacl works, then you would have to issue this every time the file is created and it would be sensible to do this as user amgr

It's probably not the best way to do it, but if there is lack of flexibility elsewhere then you may be forced this way. It's not as bad as a cron job every minute as root setting the ownership. Believe me, I've seen it.

Robin

1 Like