1 |
On Fri, Jan 19, 2018 at 07:53:06PM -0500, Michael Orlitzky wrote: |
2 |
> On 01/19/2018 07:16 PM, William Hubbs wrote: |
3 |
> > |
4 |
> > It looks like we can't use your --as suggestion if we want to be |
5 |
> > able to create paths in /var/lib and /var/spool that are owned by |
6 |
> > non-privileged users because of the permissions on those paths. It is |
7 |
> > possible that service scripts are doing this. |
8 |
> > |
9 |
> |
10 |
> Why not? Since /var/lib is root:root and mode 755, we can create |
11 |
> /var/lib/foo while running --as=root (the default). Then afterwards, |
12 |
> anything beneath /var/lib/foo would need to be created "--as" the owner |
13 |
> of that directory. |
14 |
|
15 |
That would create an extra level of indirection for some things though, |
16 |
what if /var/lib/foo needs to be owned by foo? I have /var/lib/dhcp |
17 |
which is owned by dhcp:dhcp. You can't creat that with --as=dhcp. |
18 |
|
19 |
> |
20 |
> /var/lib or /var/spool should be no different than /run in that regard. |
21 |
> |
22 |
> (Although, the ebuild should be responsible for /var/lib and /var/spool) |
23 |
> |
24 |
> |
25 |
> > Is it worth changing the algorithm to do this instead: |
26 |
> > |
27 |
> > 0. test for existance by opening a read-only file descriptor to this |
28 |
> > file. |
29 |
> > 1. Creating the file/directory/fifo. |
30 |
> > a. If it doesn't exist, create it -- note that I'm not setting |
31 |
> > permissions with the create call. |
32 |
> > b. Open a read-only file descriptor that attaches to the newly created |
33 |
> > file. |
34 |
> > 2. Setting Permissions. |
35 |
> > a. Fix the permissions of the file if necessary. |
36 |
> > 3. setting ownership |
37 |
> > a. Set the ownership if it doesn't match the specified ownership. |
38 |
> |
39 |
> Is this for checkpath? Steps (a) and (b) would need to happen at the |
40 |
> same time. Is there a way to determine if a file descriptor is for a |
41 |
> hard link? There are likely some small ways that we could still improve |
42 |
> checkpath, but the main issue I'm trying to solve by jumping through all |
43 |
> these hoops is the hard link race condition. |
44 |
|
45 |
You mean steps 1 (a) and (b)? They would happen in the sequence shown. |
46 |
The only call that gives you a file descriptor is open() which is not |
47 |
used to create a directory or a fifo. |
48 |
|
49 |
The link status is available via fstat() or stat(). |
50 |
An example of checking it is in line 146 of checkpath.c. We refuse to |
51 |
chmod a file that has more than one hard link to it. |
52 |
|
53 |
> |
54 |
> |
55 |
> >> Risk #2: Instead consider a four-component path /run/foo/bar/baz. If you |
56 |
> >> start creating those directories with owner "foo", then when you get to |
57 |
> >> creating "baz", it's possible that "bar" has been replaced by a symlink |
58 |
> >> somewhere else. |
59 |
> > |
60 |
> > It is possible, sure, but the question I would ask is, could this also |
61 |
> > be a legit situation where a user would want /run/foo/bar to be a |
62 |
> > symlink to some other location? If it is, there's no way to tell the |
63 |
> > difference. |
64 |
> |
65 |
> The init script author can use the real path instead of the one |
66 |
> involving the symlink if he needs to. So maybe he wants /run/foo/bar to |
67 |
> be a symlink to /herp/derp, but then instead of doing |
68 |
> |
69 |
> newpath /run/foo/bar/baz |
70 |
> |
71 |
> he could do |
72 |
> |
73 |
> newpath /herp/derp/baz |
74 |
> |
75 |
> and then there are no symlinks involved. |
76 |
|
77 |
Let me think about this... :-) |
78 |
|
79 |
William |