From: Sergey Gorenko <sergeygo@nvidia.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Max Gurtovoy <mgurtovoy@nvidia.com>
Subject: RE: [PATCH] srp_daemon: Avoid extra permissions for the lock file
Date: Tue, 15 Sep 2020 08:10:08 +0000 [thread overview]
Message-ID: <BN8PR12MB32208D60B5E5E1AFBDBAF0CCBF200@BN8PR12MB3220.namprd12.prod.outlook.com> (raw)
In-Reply-To: <7027c39a-1435-c4eb-d42f-c7fe272456a8@acm.org>
> -----Original Message-----
> From: Bart Van Assche <bvanassche@acm.org>
> Sent: Monday, September 14, 2020 7:56 PM
> To: Sergey Gorenko <sergeygo@nvidia.com>
> Cc: linux-rdma@vger.kernel.org; Max Gurtovoy <mgurtovoy@nvidia.com>
> Subject: Re: [PATCH] srp_daemon: Avoid extra permissions for the lock file
>
> On 2020-08-19 07:17, Sergey Gorenko wrote:
> > There is no need to create a world-writable lock file.
> > It's enough to have an RW permission for the file owner only.
> >
> > Signed-off-by: Sergey Gorenko <sergeygo@nvidia.com>
> > Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
> > ---
> > srp_daemon/srp_daemon.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/srp_daemon/srp_daemon.c b/srp_daemon/srp_daemon.c index
> > f14d9f56c9f2..fcf94537cebb 100644
> > --- a/srp_daemon/srp_daemon.c
> > +++ b/srp_daemon/srp_daemon.c
> > @@ -142,7 +142,6 @@ static int check_process_uniqueness(struct
> config_t *conf)
> > return -1;
> > }
> >
> > - fchmod(fd,
> S_IRUSR|S_IRGRP|S_IROTH|S_IWUSR|S_IWGRP|S_IWOTH);
> > if (0 != lockf(fd, F_TLOCK, 0)) {
> > pr_err("failed to lock %s (errno: %d). possibly another "
> > "srp_daemon is locking it\n", path, errno);
>
> I think the fchmod() call was introduced by commit ee138ce1e40d ("Cause
> srp_daemon launch to fail if another srp_daemon is already working on the
> same HCA port."). Has it been verified that with this change applied that
> mechanism still works?
>
> Anyway, please add a reference to that commit in the patch description.
>
> Thanks,
>
> Bart.
>
Bart,
I tested the patch for the following scenarios:
* Start the srp_daemon service when srp_daemon is not running and the lock file does not exist.
* Start the srp_daemon service when srp_daemon is not running and the lock file exists.
* Start the srp_daemon service when srp_daemon is running and the lock file exists.
* Start the srp_daemon service when srp_daemon is running and the lock file exists and the file owner is not root. (Such scenario can happen if someone tries to run srp_daemon manually as not root. The srp_daemon fails in this case, but the lock file is created). This case is handled successfully even without the fchmod() call because the srp_daemon service starts srp_daemon as root.
I do not know any case when fchmod() is needed. And it does not look like a good idea to create a word-writable file owned by root. That's why I want to remove the fchmod() call.
Do you have an idea when the fchmod() call can be needed?
If you have no other objections, I will add the fixes line and send V1.
Thanks,
Sergey
next prev parent reply other threads:[~2020-09-15 8:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 14:17 [PATCH] srp_daemon: Avoid extra permissions for the lock file Sergey Gorenko
2020-09-14 9:24 ` Sergey Gorenko
2020-09-14 16:50 ` Bart Van Assche
2020-09-14 16:56 ` Bart Van Assche
2020-09-15 8:10 ` Sergey Gorenko [this message]
2020-09-15 20:32 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BN8PR12MB32208D60B5E5E1AFBDBAF0CCBF200@BN8PR12MB3220.namprd12.prod.outlook.com \
--to=sergeygo@nvidia.com \
--cc=bvanassche@acm.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mgurtovoy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).