Bug 1764368 - Review Request: duc - a collection of tools for inspecting and visualizing disk usage.
Summary: Review Request: duc - a collection of tools for inspecting and visualizing di...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: FE-DEADREVIEW
TreeView+ depends on / blocked
 
Reported: 2019-10-22 21:28 UTC by Robert Führicht
Modified: 2020-09-11 00:45 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-09-11 00:45:23 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Robert Führicht 2019-10-22 21:28:23 UTC
SPEC URL: https://copr-be.cloud.fedoraproject.org/results/fuero/duc/fedora-rawhide-x86_64/01072057-duc/duc.spec
SRPM URL: https://copr-be.cloud.fedoraproject.org/results/fuero/duc/fedora-rawhide-x86_64/01072057-duc/duc-1.4.4-8.git5a40efd.fc32.src.rpm
Upstream URL: https://duc.zevv.nl/

Description from the package's homepage:

> Duc is a collection of tools for inspecting and visualizing disk usage.
> Duc scales quite well, it has been tested on systems with more than 500 million files and several petabytes of storage. 

Comments:

This was featured in the Fedora Magazine, but hasn't made it into the review process yet. So here's my (opinionated) take on this package.

My proposed usage (and the reason for service files, a config file for root, and the SELinux policy) is:

- Have a system-wide index available to root in /var/cache/duc, which is updated without restriction daily and is used when root calls "duc ui".
- Have a service available for users they can use to index their homedirectory.

rpmlint output:

duc-selinux.noarch: W: no-documentation
duc.x86_64: W: incoherent-version-in-changelog 1.4.4-9.git5a40efd ['1.4.4-8.git5a40efd.fc30', '1.4.4-8.git5a40efd']
duc.x86_64: W: non-etc-or-var-file-marked-as-conffile /root/.ducrc
duc.x86_64: W: hidden-file-or-dir /root/.ducrc

Comment 1 Michael Schwendt 2019-11-04 20:58:33 UTC
It really must not store any packaged files in user home directory, and that it includes /root.


> %clean
> make distclean

This section is for more general cleaning up after a build and should not be overridden like that.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_tags_and_sections


> %defattr(-,root,root,-)

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_permissions


> duc.x86_64: W: incoherent-version-in-changelog 1.4.4-9.git5a40efd ['1.4.4-8.git5a40efd.fc30', '1.4.4-8.git5a40efd']

Your package release is 8, while your changelog entry refers to 9.

Comment 2 Robert Führicht 2019-11-11 08:53:24 UTC
Michael, thanks for your review - I fixed the things you mentioned except this one:

> It really must not store any packaged files in user home directory, and that it includes /root.

I'm unsure about how to make duc behave in the way I want then - see the remark about proposed usage.

The possibilities I came up with are these:

- Provide a system-wide ducrc: Doesn't work, as this would need user-specific default overrides.
- Provide a rc file for root: Against packaging policy.
- Set DUC_DATABASE=/var/cache/duc for root (and only root):
  - /etc/environment is out, as it concerns all users.
  - Dotfiles for root are out, packaging policy again.
  - /etc/profile.d/ drop-in works, but is shell-specific.

So should I drop this and consider this not the packager's job, or is there something I'm missing?

Comment 3 Petr Menšík 2020-07-16 23:24:29 UTC
/root/.ducrc is not possible and very wrong. It should be quite simple to just make that directory default, if uid=0 was detected. Runtime from the code. Just make some ifs in the code.

Or pass db directory to service parameters. System level service would use system cache, user started service might use just home cache.

It might also just check access rights to default system cache. If no right to write there, just create and use cache directory in $HOME/.cache/duc.
Please take into account it might run under sudo, where $HOME is not root's. It might work to provide also shell wrapper, which would change DUC_DATABASE.

For example:
#!/bin/sh

if [ "$(id -u)" = 0 ]; then
  DUC_DATABASE=/var/cache/duc
fi

duc "$@"

But I think getuid() kernel call in the code would be better than similar shell wrapper. Check man 2 getuid. But I like access("/var/cache/duc", W_OK) check more, because it would allow also access by group rights.

It is quite unusual to provide own selinux policy files. Why are they required?

Also, it seems wrong to have privileged duc index command and duc gui for displaying it. I think duc-index separate command would be more secure. Only it would have elevated privileges to read other users data.
Reading indexed data should not require any extra privileges, just read permissions to indexed database. But current binary cannot set different selinux contexts to different actions. Maybe duc-indexd would be better name, to indicate it is usually run as a daemon, indexing service. It might work with shell wrapper around duc index, which would have different context. Similar to what I used above.

Comment 4 Petr Menšík 2020-07-16 23:32:34 UTC
It seems like this is advanced ncdu tool with a bundled cache. Might be quite nice to have.

Comment 5 Petr Menšík 2020-08-11 09:58:29 UTC
(In reply to Robert Führicht from comment #2)
> Michael, thanks for your review - I fixed the things you mentioned except
> this one:
> 
> > It really must not store any packaged files in user home directory, and that it includes /root.
> 
> I'm unsure about how to make duc behave in the way I want then - see the
> remark about proposed usage.
> 
> The possibilities I came up with are these:
> 
> - Provide a system-wide ducrc: Doesn't work, as this would need
> user-specific default overrides.
> - Provide a rc file for root: Against packaging policy.
> - Set DUC_DATABASE=/var/cache/duc for root (and only root):
>   - /etc/environment is out, as it concerns all users.
>   - Dotfiles for root are out, packaging policy again.
>   - /etc/profile.d/ drop-in works, but is shell-specific.
> 
> So should I drop this and consider this not the packager's job, or is there
> something I'm missing?

Why don't you set environmnent (In reply to Robert Führicht from comment #2)
> Michael, thanks for your review - I fixed the things you mentioned except
> this one:
> 
> > It really must not store any packaged files in user home directory, and that it includes /root.
> 
> I'm unsure about how to make duc behave in the way I want then - see the
> remark about proposed usage.
> 
> The possibilities I came up with are these:
> 
> - Provide a system-wide ducrc: Doesn't work, as this would need
> user-specific default overrides.
> - Provide a rc file for root: Against packaging policy.
> - Set DUC_DATABASE=/var/cache/duc for root (and only root):
>   - /etc/environment is out, as it concerns all users.
>   - Dotfiles for root are out, packaging policy again.
>   - /etc/profile.d/ drop-in works, but is shell-specific.
> 
> So should I drop this and consider this not the packager's job, or is there
> something I'm missing?

Maybe set DUC_DATABASE from systemd unit. I doubt there is reason why root should have different behaviour from other users. Instead, prepare systemd service for running the service on system level. And allow users to run own instances as user level. I have suggested few ways. Is any of them suitable to you?

Comment 6 Petr Menšík 2020-08-20 07:56:35 UTC
Due to lack of responses I leave this review for anyone other.

Comment 7 Package Review 2020-09-11 00:45:23 UTC
This is an automatic action taken by review-stats script.

The ticket submitter failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we consider this ticket as DEADREVIEW and proceed to close it.


Note You need to log in before you can comment on or make changes to this bug.