[LU-11850] Relocating /proc/fs/lustre/ost to /sys/kernel/debug/lustre/ost prevents non-root access

• Type: Bug
• Resolution: Unresolved
• Priority: Minor
• Fix Version/s: Upstream
• Affects Version/s: Lustre 2.12.0
• Labels: llnl
• Severity: 3
• Assignee: James A Simmons
• Reporter: Mahmoud Hanafi

Description

For security reasons /sys/kernel/debug is restrict to root only so by relocating /proc/fs/lustre/ost & mdt to /sys/kenrnel/debug/lustre breaks many tools such as 'performance co pilot" that run as non-privilege users. We rely on such tools to collect lustre metric.

We could change the permissions on /sys/kernel/debug but that is not good security practice. Can there be a build option to selected the location?

Issue Links

• is duplicated by: LU-11988 Some lctl *_param values only readable by root
• is related to: LU-11988 Some lctl *_param values only readable by root
• is related to: LU-12244 lfs check subcommand no longer works as non-root user
• is related to: LU-12513 Address YAML limitations
• is related to: LU-17471 Add symlink /proc/fs/lustre/osd-*/*/brw_stats to /sys/kernel/debug/lustre/osd-*/*/brw_stats
• is related to: LU-18709 High frequency performance counters accessible to non-root users
• is related to: LU-12841 Add ability for lctl get_param to get subfield of YAML output
• is related to: LU-16164 Check params and make them valid YAML if they are designed to be
• is related to: LU-17472 Create programming wrappers (python, go) for liblustreapi Netlink stats API
• is related to: LU-8066 Move lustre procfs handling to sysfs and debugfs.
• is related to: LU-9680 Improve the user land to kernel space interface for lustre

Comments

[James A Simmons]

The kernel has rules about what can be in sysfs. An excellent article covering these rules is here:

https://lwn.net/Articles/378884

Since Lustre has complex data files they are not allowed in sysfs. So the quick fix done for the linux client was moving it to debugfs . The point of this policy was due to proc becoming a dumpster. Now the dumpster is debugfs  Note I have been avoiding the move of several files like stats to debugfs for the OpenSFS tree.

No fear netlink will resolve these issues. I have a prototypes partially working. I just need to work out the nesting of data. I see its the ptlrpc service stats.

[Mahmoud Hanafi]

But why are we considering /sys/kenrel/debug/lustre/ost/... part of "debugging"

 

[James A Simmons]

Because all debugfs files go into /sys/kernel/debug. That is the mount point.

[Mahmoud Hanafi]

Why is /sys/kernel/debug/lustre not located at /sys/kernel/lustre?

[Jay Lan (Inactive)]

James, this is great! Performance is very important! Thanks!

[Andreas Dilger]

We could change the permissions on /sys/kernel/debug but that is not good security practice.

There is no need to change the permissions for the whole of /sys/kernel/debug to be world readable. Currently, it looks like /sys/kernel/debug is itself the only directory that blocks access. It would be possible in the short term to recursively change the permissions of this tree to remove world-readable permissions ("chmod -R go-rw /sys/kernel/debug") and then enable group access permissions for the monitoring tools to the Lustre tree after the filesystem is mounted ("chmod -R g+rX /sys/kernel/debug/lustre; chgrp -R collectd /sys/kernel/debug/lustre" or similar).

[Peter Jones]

ok James

[James A Simmons]

BTW here is an excellent article about a solution which I'm modeling my work after.

https://lwn.net/Articles/406975

The article cover why stats in proc is bad.

[James A Simmons]

Proc is the worst place for this kind of information. Not only is frowned on by the kernel maintainers but if we every placed a large amount of data into an seq_file, which is used by procfs, the node would be brought to its knees by the cpu load. Actually this has been under discussion on the lustre-devel mailing list. If you are talking about "stats" I'm working a netlink implementation which is way more flexible and has better performance. Give me a few days to roll something out.

[Jay Lan (Inactive)]

I think the question we should ask is "should the information revealed in lustre/ost and lustre/mdt be kept away from non-privileged users?" If not, maybe we can reconsider the decision and move the information back to procfs? Or other sysfs location that do not require root privilege to read?