This applet checks for the existance of a directory and optionally checks its ownership. The syntax is "checkdir -d <directory> [-o <owner:group>]". This is required in some of the init scripts for a proper support of tmpfs /var/run (see bug 181527). Unfortunately not all packages support this feature, as they rely on the "keepdir"s created by the ebuild, which breaks stuff if the /var/run dir is mounted in tmpfs. And those who do support it, do not use an "unified way" to do it. So this is the reason for this simple applet. I've created it against baselayout 2 because I don't have baselayout 1, but I guess it would be simple to port, as it is a simple "mkdir -p <dir> && chown <owner:group>" made in c. I've named it checkdir because I couldn't think of any other name, so please feel free to change it to something more appropriate.
Created attachment 131042 [details, diff] The patch against baselayout 2 This patch is against baselayout-2.0.0_rc4
i dont see why people cant just run `mkdir` and such, but that's me ... you should have [-m mode] in there, and considering checkdir *requires* a directory, having the -d in there is unintuitive your coding style is largely incompatible as well ... we generally use LKML which means you need to cuddle all of your "if" braces
(In reply to comment #2) > i dont see why people cant just run `mkdir` and such, but that's me ... I guess people tend to like "simple one-liners" :) > you should have [-m mode] in there, and considering checkdir *requires* a > directory, having the -d in there is unintuitive I guess I can add/correct those. > your coding style is largely incompatible as well ... we generally use LKML > which means you need to cuddle all of your "if" braces I gess I can also adapt this. Of course, all of the above changes are subject to the acceptance of the applet.. I'm not going to spend more time on it if it's going to be ditched ;)
i dont really see a problem with the thing ... Roy ?
I don't overly object to it. Possibly the concept is over engineered, but heh. Anyway, if you're going to do a job, do it properly! start-stop-daemon uses chuid/user, so lets use user instead of owner. Also, uid's should work just as good. While we're checking who owns the directory, maybe it would be a good idea to check the permissions too? checkdir --mode g+rw --user root:0 /foo/bar checkdir --mode 0755 --user 0 --group wheel /foo/bar I would expect the above two to work equally well. Maybe add options for --test and --quiet. I would expect --test to return 0 if nothing needs to be done.
symbolic mode parsing is going to be a pain, so i'd make that the last thing to implement (if we do it at all) ...
(In reply to comment #6) > symbolic mode parsing is going to be a pain, so i'd make that the last thing to > implement (if we do it at all) ... I guess we can cheat.. :) A simple "system" or equivalent call should do the trick .. Or we can borrow the code from the chmod util..
(In reply to comment #2) > (...) and considering checkdir *requires* a > directory, having the -d in there is unintuitive I've done this, but there is a caveat: the "directory" argument doesn't show up in the usage message. So there's no way of letting the user know that the directory option is required, or that it even exists. Unless we change the "usage" function.. I can do that if necessary :)
I think what Mike means is that every non option argument is a directory, like so checkdir --user root:0 /dir1 /dir2 /dir3 /dir4 So you would have this at the end of your option parsing while (optind < argc) { if (! rc_isdir (argv[optind])) { eerror ("%s: `%s' is not a directory", argv[0], argv[optind]); } else { /* Option is a directory, so check it */ check_dir (argv[optind]); } optind++; }
correct, that's what i meant
(In reply to comment #10) > correct, that's what i meant > Right, but that was not the problem I was talking about. The problem is that the usage message doesn't mention the existence of the "directory" argument(s). That may not be a problem at all, but I'm not sure.
none of our other applets presently do either :P I'll probably address that defect tomorrow, but in the meantime you should address my concerns and we'll address your one later.
Created attachment 131237 [details, diff] Checkdir patch v2, some corrections/improvements Here it is, version 2 of the patch: * support for multiple directories * hopefully more LKML-style :) The mode support is still missing. I have a separate patch that uses system("chmod foo bar") to set the mode, but that's kind of cheating ;)
Created attachment 131238 [details, diff] Checkdir patch v2, the correct one Ops, nevermind the previous one, it had the options messed up. This is the right one.
http://sources.gentoo.org/viewcvs.py/baselayout/trunk/src/checkown.c?view=markup I've added the applet as checkown as it could be used to check files also. It currently accepts --mode 0522 as well, but it's not parsing g+w type ones. Of course it could be made to if needed. Thanks!
Nice :) [how] can it be ported to baselayout 1? I'd really like to see the init scripts using it for creation of /var/run dirs :)
I have no interest in backporting it to baselayout-1.
(In reply to comment #17) > I have no interest in backporting it to baselayout-1. > Hum but then it will only be used when baselayout 2 becomes stable and baselayout 1 gets removed from portage. Otherwise it would make no sense to change the init scripts, as they would become incompatible.. And judging from the lack of interest from the "hardened" guys, it may take some time for baselayout v1 to be removed..
(In reply to comment #18) > Hum but then it will only be used when baselayout 2 becomes stable and > baselayout 1 gets removed from portage. Otherwise it would make no sense to > change the init scripts, as they would become incompatible.. That is true. There are other new init script features also waiting in the wings, checkown is not unique in this respect. > And judging from the lack of interest from the "hardened" guys, it may take > some time for baselayout v1 to be removed.. hardened team has no say in this afaik. It's just the arch teams that matter and the only ones currently not keyworded are the obscure ones vapier maintains.
*** Bug 205183 has been marked as a duplicate of this bug. ***
